barmic 🦦 a écrit 5948 commentaires

Le temps d'une version ou deux. Et c'est justement le souci avec Ubuntu : ça lance des trucs mais pas vraiment de suivi sur le long, ça girouette d'une version à une autre :s

Tu as des éléments pour dire ça ou c'est juste du pif ? Parce que canonical reste principal développeur d'apparmor (donc ils continuent de payer des gens pour travailler dessus) et la dernière version et sortie avant hier et la précédente 5 mois avant. Pourtant quand Canonical abandonne quelque chose ils ne semblent pas faire dans la demi mesure comme avec upstart.

https://gitlab.com/apparmor

Je crois bien que la communauté n'est pas si motivée que ça.

Encore une fois tu as des éléments ? Après que l'impossibilité viennent d'une question technique ou de l'impossibilité pour la communauté de s'y mettre, ça ne change pas le problème.

Euh… y a que les versions vraiment requises dans mon souvenir. Si t'as 5 logiciels qui ont besoin de 3 versions différentes d'une bibliothèque tu te retrouve avec trois version et non cinq !

Ça dépend de comment c'est fait, mais comme pour snap/flatpack ça demande de tout rebuild il me semble. Mais tout est fait pour te permettre de ne pas respecter ça. Et certaines descriptions (comme on peut en trouver ici même vont préconiser d'au contraire verrouiller tes dépendances et c'est logique c'est l'une des raisons d'être de nix).

SELinux tout en trouvant que c'est bien que ce ne soit pas activé par défaut dans les distros grand public (c'est pas top en terme de sécu mais c'est plus simple pour la cible)

C'est bien pour ça que certains tentent d'autres approches fournissant plus de sécurité tout en restant plus simples.

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

Oui, on pourrait améliorer AppArmor (pas taper) ou intégrer Nix par exemple

Parce que personne n'y a pensé ? C'est justement Canonical qui a mis pas mal de billes dans AppArmor depuis pas mal de temps, ils ont peut être une idée de ce qu'on peut arriver à faire ou non avec ? C'est peut être un choix stratégique de leur par, mais bon des LSM on en a 4 ou 5 (apparmor donc mais aussi selinux, smack, tomoy et le plus récemment mergé au noyau landlock). À ma connaissance malgré les années (SELinux a 22 ans), seul selinux est véritablement démarré en mode actif uniquement sur rhel et consort… AppArmor a lui même était créé pour simplifier SELinux. Je ne sais pas si c'est possible ou pas d'améliorer AppArmor, mais je suis certains que si quelqu'un a une idée la communauté et preneuse parce qu'elle n'a pas l'air de s'en sortir (pour le déployer sur du grand publique donc hors de machines à usage plus ou moins dédiées administré par quelqu'un de motivé pour activer et configurer les règles). Perso j'apprécie les principe je suis pas contre les LSM ni un en particulier, mais ça semble complexe de le déployer en grand publique (et j'entends par là qu'il soit lancé en mode restrictif).

Quant à nix, ça fais exactement ce que tu ne veux pas, c'est à dire avoir 37,972 versions de la même bibliothèques pour que chaque logiciel puisse linker avec celle dont il a envie, le tout en prenant un max de place.

Au passage, existe-t-il une étude qui corrobore l'aspect sécurité quand on multiplie les même bibliothèques avec des mises à jour réparties au petit bonheur ?

Et est-ce qu'il en existe une qui corrobore que le principe de moindre privilège n'est pas prépondérant aux mises à jour ?

Tu trouvera rien pour ça amha et d'autant plus quand c'est pour des machines de bureaux.

Mais bon en soit l'un empêche pas l'autre, il n'y a pas de raison de les mettre en opposition. D'autant que si j'ai bien compris ubuntu se dirige vers la fourniture de snap comme d'autres fournissent des rpm et donc de reconstruire et mettre à jour tous leur snap quand ils veulent mettre à jour une bibliothèque.

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

De ce qu'on m'avais expliqué.

Car si on les diluent, elle sont en quelques sortes toujours ajoutées et il y'a forcément des systèmes plus critiques où le mensonge n'est pas envisageable et donc qui devraient continuer à la gérer comme actuellement (donc je pense que ce n'est pas le sens de la proposition).

Les systèmes les plus critiques ne font jamais aucun changement d'heure ni ralentissement ni accélération. Ils gèrent une heure interne qui est stable et qui garde continuellement les propriétés dont ils ont besoin et convertissent l'heure quand il faut "sortir" cette heure.

C'est un peu comme changer ou non l'heure du bios quand tu change l'heure de ton OS.

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

Bof, hein. Il y a aussi un tas de projets totalement open source qui marchent.

Pour un qui marche combien échouent ?

Les 3 projets que tu cite, en étant pas très sympa Mongo et elastic ayant quitté les licences licences libres alors que docker propose simplement un outil et des services à côté qui sont payants, sont dans un domaine où ils ont en face d'énormes prédateurs qui sont en position de monopoles ou quasi monopoles.

Mongo et ES ont essayé et ont échouer à suivre leur développement en libre. C'est tout aussi intéressant que de regarder ceux qui marchent, mais il faut replacer les projets dans leur contexte pour comprendre comment est ce que ça peut marcher ou pas.

Le succès n'est pas une question d'être le meilleur, mais une question de positionnement, de chance, d'opportunités,… La qualité intrinsèque joue mais ce n'est qu'un élément parmi d'autres.

Pour moi, L'open source ne devrait pas se limiter au confort des développeurs, mais s'adresser avant tout aux utilisateurs finaux, parce c'est pour elles et eux qu'on bosse au final.

Alors si déjà personne n'a de devoir comme ça surtout à ses dépend (consommer de son temps, de son énergie et de son argent), mais en plus si les développeurs ne peuvent pas vivre de leur projet ça ne va pas donner le même résultat final.

Vivre du libre n'est pas impossible mais est compliqué. Pour un certain nombre qui réussissent voir qui réussissent très bien un paquet échouent. La faute à pas de chance pour une partie, mais aussi du fait que le succès ne dépend pas que du code, mais aussi de sa communication¹, de son positionnement,… Monter un projet dont on veut vivre n'est pas très différent de monter une entreprises sur bon nombre de sujets.

Faire culpabiliser ceux qui essaient et tenter de leur faire de grandes leçons de morale n'aide pas à mon avis.

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

Il dit que des classes clairement annoncées comme ne faisant pas partie du standard avec 0 garanties de maintenance ne peuvent pas être utilisée comme exemple de cassage d’api/abi.

Oui mais c'est ce que je dis tu ne peut pas les ignorer pour autant parce que ce sont des fonctionnalités qui constituent dans les faits une partie de la plateforme. Quelqu'un qui bosse là dedans qui construit un projet qu'il fourni gratuitement et dont l'écosystème bénéficie très clairement lui. Venir avec de gros sabot en disant « c'est pas dans notre contrat d'interface, donc va falloir vivre sans à partir de maintenant ». C'est non seulement arrêter net une dizaine de projets parmi les plus populaires de la plateforme, mais aussi donner un grand signal à toute la communauté que quelque soit ce que tu aura apporté, tu peux te faire dégager ton projet si tu ne rentre pas tout à fait dans ce qui a était contractualisé.

Encore une fois, les contributeurs d'OpenJDK ont tout à fait acté ce fait et ont abandonné leur objectif de retirer Unsafe tant qu'ils n'auront pas d'alternatives.

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

Si tu veux un programme en mode graphique… Tu connais beaucoup de bibliothèques graphiques C ① multi-plateformes et ② qui n’ont pas cassé leur API au moins une fois au cours des vingt dernières années ?

C n'était qu'un exemple, mais des bibliothèques qui n'ont pas cassées ça se trouve oui, la première qui me vient à l'esprit c'est évidement Tcl/Tk. Mais c'est vraiment des gens qui ont choisi java pour swing ?

Si le prix à payer pour ça est de devoir continuer à utiliser Java8 (par ailleurs toujours officiellement maintenu, contrairement à Python2 par exemple) le temps de trouver les ressources pour porter ce qui doit l’être vers une version plus moderne, ben ça me semble un prix bien modique.

Pas moi adoptium fourni le JDK8 jusqu'en 2026, le JDK11 jusqu'en 2024, le JDK17 jusqu'en 2027, le prochain JDK en LTS sera le JDK21 qui sortira en 2023 et dont le support ira jusqu'à 2028.

L'absence de mise à jour de la plateforme c'est à minima plus de mise à jour de LTS comme du reste de la partie crypto. Et je ne te parle pas du support de plateforme comme les nouvelles d'Apple.

Donc ils vont faire quoi ? Attendre 2026 pour tenter tant bien que mal de faire une migration 13 versions ? Et c'est à ce moment là qu'ils vont rugir que vraiment la compatibilité de java c'est pas top ? À partir de là ils n'auront plus que des version dont le support restera 4 ans.

Si comme tu le dis c'est compliqué structurellement de faire des mises à jours de java ces 8 dernières années, ils vont vivre un enfer tout en sortant des versions potentiellement buguées et relativement loin de l'état de l'art de la plateforme qu'ils utilisent (parce que ça prends du temps d'utiliser correction les records, de profiter des threads légers, etc).

Ils font bien ce qu'ils veulent (d'autant que les perspectives en 2000 n'étaient pas celles d'aujourd'hui), je n'utilise pas leur logiciel, je ne connaît pas toute leur problématique et je serait très content pour eux si tout marche comme sur des roulettes, mais à mon humble avis la vie d'apparente insouciance risque fort dans une certaine douleur.

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

Pour le coup java souffre plus d'une image que de faits.

Alors pour le coup, quand je lance un programme et qu’il crashe au démarrage, pour moi c’est un fait et pas une image. :p

Ça ne veut pas dire que c'est compliqué à corriger.

Bienvenue dans le monde des projets académiques. Votre première mission, si vous l’acceptez, sera d’obtenir des financemements pour tenir ce programme à jour, en justifiant auprès des organismes de tutelles que vous n’allez ajouter aucune fonctionnalité, juste permettre au programme de continuer à fonctionner comme avant.

C'est un mauvais choix de plateforme. Tu as des tas de plateformes largement plus stable. Si tu écris ton projet en C89 tu pourra ne rien toucher tant que gcc/clang supporteront ce standard et il n'y a aucune planification à ma connaissance pour le retirer. C'est quelque chose à prendre en compte.

Mais du coup, quand j’entends quelqu’un vanter la rétro-compatibilité de Java en disant qu’un programme écrit il y a vingt ans peut toujours tourner sur un JRE moderne, on est d’accord que j’ai le droit de rire jaune ?

Oui (d'autant que du coup j'ai pas compris ce qu'il voulait dire par "saint"), je dis tout de même que ce n'est pas soit tout noir soit tout blanc.

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

Dans ce cas pour moi on ne parle pas de la même chose. Je parle de la rétrocompatibilité des ABI et API uniquement, pas de la plateforme en entier.

C'est un déplacement du problème pas une correction.

Pour les sealed, tous les enum sont sealed. J'ai découvert pour l'occasion que tu pouvais mock un enum avant (et qu'on avait un test qui s'en servait), c'est une (très) mauvaise idée amha, mais tu ne peux plus à partir de java17.

On a jamais pu étendre un enum. Si un outil de test se servait d'une bidouille pour forcer quelque chose de normalement impossible (ici : créer une classe de mock qui étends l'enum) et que ça finit par péter, c'est pas de chance, mais pour moi c'est pas un problème de rétrocompatibilité : le comportement n'avait jamais été prévu ni officialisé.

Parce que non seulement ils cassent la compatibilité, mais en plus ils déprécient des parties (le plus connu c'est quand ils ont souhaité déprécier sun.misc.Unsafe).

Pour moi déprécier sun.** n'est pas « casser la rétrocompatibilité », puisque Sun puis Oracle ont toujours dit que ces packages étaient à usage interne, ne faisaient pas partie de l'API et ne devaient pas être utilisés. D'ailleurs des programmes qui utilisaient ces classes ne fonctionnaient pas sur des JVM non-Sun/Oracle, à commencer par la JVM d'IBM.

Sun comme Oracle ont très largement profité du fait que les gens avaient ces possibilités. Le succès de la plateforme n'aurait pas du tout était la même sans ça. Je trouve que prendre tous ces gens qui ont largement contribué à la plateforme de haut en leur disant que leurs usages "bof OSEF lol" est un manque de respect total.

Oui la plateforme a besoin pour évoluer de trancher certains usages, mais ça n'empêche pas de prendre en compte l'état réel de la plateforme et pas ce que ce serait dans un état imaginaire qui ne prendrait en compte que ce qui est spécifié/contractualisé.

Très basiquement retire toutes les bases de données de java (cassandra, elasticsearch, neo4j,…) ça va nettement impacter la plateforme. Même les membres d'OpenJDK l'ont entendu.

Le fait que Java n'hésite pas à faire des doublons d'API, mais surtout des montages compliqués, des tonnes de sucre syntaxique qui masquent des pièges et finissent par aboutir à des demi-solutions bancales et peu pratiques.

swing/awt était une fierté fut un temps (pas si lointain).

Par exemple et sans réfléchir : tout le système de boxing/unboxing, le type erasure dans les generics, la (non) gestion des checked exceptions dans les lambda – qui en plus n'a pas de solution élégante dans l'API standard.

Les exceptions checkeds sont gérées d'une manière cohérente dans les lambdas et heureusement. Il y a déjà largement suffisamment de cas particulier lié aux lambdas pour ne pas ajouter ça. Une partie du reste est entrain d'être traités par différents sous projets d'OpenJDK.

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

[…] mais à quel point c'est imputable à une non rétrocompatibilité de l'ABI ou de l'API de Java ?

Virer une partie de la bibliothèque standard c'est clairement une rupture de rétrocompatibilité de l'API.

Pour ImageJ, ils utilisent assez massivement le moteur JS intégré à Java… qui a changé et finalement été supprimé. Là effectivement, c'est dommage, ils ont parié sur une solution non pérenne pour leur outil.

Le retrait de nashorn est une bonne nouvelle. Il était pas très à jour sur l'implémentation emscscript et on a aujourd'hui des solutions bien plus performantes comme graalvm polyglot

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

Les ruptures de compatibilités n'ont rien d'incroyables non plus. Pour le coup java souffre plus d'une image que de faits. Même si tes projets l'affirme. Annoncer la bouche en fleur rester compatible uniquement avec java8 8 ans après c'est comme un projet qui te dit qu'il n'est compatible qu'avec python2.7 sauf qu'avec java tu n'a pas d'opérateur qui claque silencieusement, tu n'a pas tes chaines de caractères/tableaux d'octets qui changent de comportement silencieusement.

Pour être du sujet, je considère ça comme de la pure dette technique qu'y est procrastinées à outrance. Le monde n'est pas binaire entre soit c'est parfaitement compatible soit c'est infernal et les ruptures ne sont pas très douloureuses. Et oui mettre à jour sa version de java fait parti du langage comme quand tu choisi python ou lua et les choses ne vont pas s'améliorer avec le temps. release early, release often s/release/update/g

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

Même question que ci-dessus : est-ce que tu as des exemples ?

Pour les modules et les sealed, je vois bien les problèmes de compatibilité mais je n'ai pas entendu parler de problèmes de _rétro_compatiblité au sens ci-dessus.

Ah non je n'ai pas dis que c'était en particulier des problèmes d'ABI.

Pour les modules, à partir de java11, tu dois déclarer tes modules à ouvrir à ouvrir tout puis à partir de java17 tu ne peux plus tout ouvrir il faut lister tous les modules au quel tu souhaite accéder. Pour moi si tu faisais :

java -jar appli.jar

avec java8 et qu'en mettant à jour java la commande tel quelle ne fonctionne plus c'est un problème de rétrocompatibilité. Que tu ajoute cette liste de modules dans le module info dans le jar ou via la ligne de commande ne change rien.

Pour les sealed, tous les enum sont sealed. J'ai découvert pour l'occasion que tu pouvais mock un enum avant (et qu'on avait un test qui s'en servait), c'est une (très) mauvaise idée amha, mais tu ne peux plus à partir de java17. Moi j'en ai aucun usage, mais je serais pas vraiment surpris qu'un outil s'en serve pour une raison ou une autre (même un spoke par exemple).

Je retrouve plus la référence mais en ajoutant une méthode sur une interface des collections ils ont cassé la compatibilité d'eclipse-collections. Je présume que ça n'est pas le seul cas où c'est arrivé (pour eclipse ou autre).

Enfin et surtout, « sainte » ≠ « absolue » hein.

Mais du coup tu entends quoi par « sainte » ? Parce que non seulement ils cassent la compatibilité, mais en plus ils déprécient des parties (le plus connu c'est quand ils ont souhaité déprécier sun.misc.Unsafe). Probablement pas autant que tu le souhaiterais, mais du coup je ne vois pas ce que tu entends par « sainte compatibilité ».

Aujourd'hui, mi-2022, tu peux écrire du code complet à base de Vector, HashMap, Date et autres objets qui ont des remplacements bien plus pratiques sans que le langage ne te sorte le moindre avertissement.

Quel est le remplacement de HashMap ? Je viens de vérifier je ne vois pas dans le standard ce qui ces dernières versions auraient donné de quoi le déprécier.

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

Présenté comme ça je dirais que tout langage qui permet l'introspection a ce problème. Si je compte le nombre de méthodes d'un objet python, j'ai strictement le même problème.

Mais ça me gratte un peu parce que c'est pour moi un bug de l'utilisateur pas du langage ou de la bibliothèque.

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

Elle n'est pas si sainte que ça. Tu as eu plusieurs changements de compatibilité ces dernières années.

• les modules ont eu des effets
• le passage de java ee à jakarta
• les sealeds ont eu des effets de bords
• le retrait de nashorn
• d'autres trucs dont j'ai plus le souvenir exact

Rien de très méchant et tu as des discussions pour être encore plus disruptif.

Java n'est pas si rigoriste que ça

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

De ce que j’en voit, sortis de languages récents et relativement peu répandu, une abi stable est un peu la base de la base.

Go s'en affranchi et la plus part des langages de scripts je présume, je ne sais pas ce qu'il en est des langages à machines virtuelle comme java. Je sais que le format de la représentation binaire est versionné, mais je ne suis pas assez familiarisé avec ce qu'est l'abi pour savoir. Si je peux changer ma représentation interne d'une classe, ne pas recompiler ceux qui utilisent cette classe et tout de même linker avec c'est qu'il n'y a pas de problème d'abi ?

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

[Tu parle donc d'une replay attaque ce qui n'a rien avoir avec le vol de ton téléphone et toutes les 2FA ne sont pas protégées contre ça effectivement parmi les 3 facteurs possibles seul celui qui prouve que tu possède quelque chose (avec TOTP par exemple) interdit le rejeu.]'https://linuxfr.org/news/pypi-deploie-le-systeme-2fa-pour-les-projets-critiques-ecrits-en-python#comment-1896446)

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

Après pour ce qui est de l'ABI, est-ce vraiment une mauvaise chose que de vouloir éviter de casser l'existant ? Je n'ai pas trop d'avis là dessus.

Personnellement je ne me prononce pas du tout là dessus. C'est probablement pas une bonne ou une mauvaise chose, mais un choix, une direction qu'ils veulent donner et c'est leur rôle.

Mais disons que si livrer un standard rapidement en s'interdisant de revoir leur copie semble vouer à produire des problèmes de plus en plus aberrants. Python nous a montré ce que donne les ruptures de compatibilité et c'est un traumatisme aujourd'hui pour beaucoup de développeurs de langage.

Il n'y a pas de tout noir ou tout blanc, mais je vois comme une contradiction l'idée de vouloir évoluer vite sans rompre la compatibilité. C'est amha un point qui fait la différence entre python et perl aujourd'hui.

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

Je reprends sans coupe ton commentaire en lien :

Relis bien le thread, mais en résumé je dis:

• qu'il ne faut pas choisir des facteurs "emmerdants" : le confort d'utilisation est un élément de sécurité ;
• que le 2FA n'est pas fait pour protéger en cas de compromission des périphériques/terminaux : si tu veux te protéger contre ça, il faut d'autres mesures.

La sécurité, c'est by design par by what could go wrong.

A propos, est-ce que quelqu'un a vu mon post-it avec marqué "root pwd : ***" dessus ? J'en ai besoin pour faire une mep.

La phrase qui m'interpelle (et que j'avais déjà cité c'est :

que le 2FA n'est pas fait pour protéger en cas de compromission des périphériques/terminaux : si tu veux te protéger contre ça, il faut d'autres mesures.

L'authentification à 2 facteurs consiste à devoir prouver 2 choses parmi :

1. ce que tu sais
2. ce que tu possède
3. ce que tu as

Si on te vol l'objet que tu as et qui te sert pour le point 1 dans une implémentation correct de la 2FA ça ne devrait pas pouvoir prouver :

• ni qui tu es, ça voudrais dire que stocke tes données biométriques et ce n'est donc plus qui tu es mais ce que tu possède
• ni ce que tu sais, ça voudrais dire que tu stocke ce que tu sais et ce n'est donc plus ce que tu sais mais ce que tu possède

Hors le nist dont j'ai donné le lien un peu plus haut affirme :

Your credentials fall into any of these three categories: something you know (like a password or PIN), something you have (like a smart card), or something you are (like your fingerprint). Your credentials must come from two different categories to enhance security – so entering two different passwords would not be considered multi-factor.

Au risque de me répéter si tous tes facteurs que tu en ai 1, 2 ou 1000 entrent tous dans « ce que tu possède », même s'il s'agit d'un objet différents pour chacun de tes 1000 facteurs, ça ne devrait pas être considéré comme du multifacteur.

J'affabule ?

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

Et puis il y a eu les propositions sur les modules, ils avaient fait une proposition très pragmatique, mais Microsoft a fait un peu du forcing et il y a eu conciliation qui a abouti à une horreur (d'ailleurs pas encore implémenté ni dans GCC, ni dans clang).

Je crois me souvenir que c'est pas la première fois que tu es très critique sur ce sujet. Je suis bien trop loin du c++ pour pouvoir juger, mais un comité de décision ISO aurait pu semblé être l'organisation parfaite pour éviter ce genre d'écueils. Privilégiant la qualité et la pérennité.

Si le comité prend des décisions qui sont aussi discutables tout en refusant de les remettre en question ensuite, ça ne va pas poser de gros problèmes pour la pérennité du langage d'après toi ? Indépendamment des choix de google.

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

Ça peut aussi être une façon d'influencer le commité. La création par facebook de hiphop puis de hhmv a donné un coup de fouet à php qui s'est vachement repris ensuite pour php8.

S'ils obtiennent une perf intéressante par rapport à C++. Détrôner C++ de sa place de langage généraliste le plus performant peut faire changer beaucoup de choses.

Même sans parler de bras de fer, peut être que les gens du commité verront d'un autre œil le fait de garder l'ABI selon ce que ça apporte dans les faits. Bref ça peut devenir une preuve de concept.

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

que le 2FA n'est pas fait pour protéger en cas de compromission des périphériques/terminaux : si tu veux te protéger contre ça, il faut d'autres mesures.

Non tu as dis et répété que 2FA n'est pas fait pour survivre à la compromission d'un seul des facteurs. Et je te dis que si un seul facteur permet l'authentification ce n'est pas du multifacteur. Après tu maintiens du flou entre les attaques par rejeu (ce à quoi tous les 2FA ne sont pas protégés) et la prise de contrôle d'un des facteurs (ce pour quoi le 2FA existe).

Que le 2FA ne soit pas suffisant c'est une évidence, qu'il faille resté vigilent c'est toujours le cas, il n'existe pas de silver bullet. Mais il ne faut pas pour autant jeter le bébé avec l'eau du bain.

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

Ça c'est une faille d'implémentation. L'authentification 2 facteur est un principe.

Encore une fois c'est comme dire que le mot de passe ne protège pas parce qu'il est toujours possible d'écrire son login et mot de passe sur sa bio twitter.

Un service qui renvoie ce genre de données sans s'être assuré de la personne qui était en face commet une faute au même titre que quand debian casse openssl.

Le principe reste valide et ce n'est pas le fait que certains l'implémentent avec les pieds qui va changer ça.

Et le principe dis explicitement que tu ne dois pas relier les facteurs entre eux. Dire "le 2FA ne protège pas du vol d'un facteur" c'est faux, par contre dire que certains pensent implémenter un 2FA mais le font tellement mal que ça n'en est pas un, c'est tout à fait légitime.

Et ça n'est pas un détail parce que tu te sert de ces problèmes pour remettre en cause le principe. C'est comme dire que tu en a marre des mots de passe alors qu'on sait très bien que des gens les écrivent sur papier.

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

D'un côté tu parle de vol de périphérique (ce que j'ai compris par comme l'un de des 2 facteur) et de l'autre tu parle de compromission du terminal.

Tu parle donc d'une replay attaque ce qui n'a rien avoir avec le vol de ton téléphone et toutes les 2FA ne sont pas protégées contre ça effectivement parmi les 3 facteurs possibles seul celui qui prouve que tu possède quelque chose (avec TOTP par exemple) interdit le rejeu.

Par contre :

C'est fait pour limiter les dégats en cas de compromission d'un facteur (on récupère ton login/password).

Aucun facteur n'est suffisant pour t'authentifier sinon ce n'est plus de l'authentification multifacteur. Si ce principe n'est pas respecté ce n'est pas du 2FA. Si je dessine un carré avec 5 côtés ce n'est pas un carré.

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

Attention le multi-facteur ne protège pas contre la compromission du périphérique

Si, bien sûr sinon ce n'est pas de l'authentification multi facteur¹. Toi tu parle de compromission du périphérique et du mot de passe.

C'est comme dire que les mots de passe ne protègent pas du mot de passe azerty.

Si l'utilisateur fragilise activement son authentification, il n'y a pas des masses de protocoles pour l'en protéger.

• ce que tu es
• ce que tu as
• ce que tu sais

Si un objet permet à lui seul de t'authentifié ce n'est pas une authentification 2 facteurs. D'ailleurs même si 2 objets différents le permettent ça ne l'est pas non plus.

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

Je tâcherai de me rappeler ton billet la prochaine fois que je démarre au quart de tour ;-)

Ma nouvelle signature t'aidera peut être

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

J'ignore le encore le seuil selon lequel tu classes une personne en tant que troll.

Il est très rare que je présume que quelqu'un est un troll. Mais un message peu l'être. C'est très différent de mon point de vu.

Par contre, il ne faut pas voir ça comme une disqualification de ma part.

Déjà tu remarquera que je n'ai même pas utilisé le mot pour te répondre.

Mais surtout, le trolling n'est pas systématiquement mauvais. Ça peut faire parti d'un foklore et ça peut même amener des discussions intéressantes¹.

La réaction me paraissait épidermique voila tout.

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll