barmic 🦦 a écrit 5783 commentaires

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

Il y a des tas de projets avec des dépôts en ligne, non? Qu'en est-il de ceux-là? Ils sont plus sécurisés? Moins?

Github s'y met aussi, npm aussi. L'authentification 2 facteurs est un mouvement de fond. On considère de moins en moins qu'un mot de passe suffit.

Quels sont les moyens de réduire les probabilités de projets malveillants?

Ça ne concerne pas les projets malveillants, mais les projets qui se font voler leur compte pour déployer du code malveillants. Il y a des cas documenté chez pypi et npm depuis plusieurs années.

En ont-ils déployé? A-t-on constaté des résultats? Quels sont-ils? Peut-on en déduire quelque chose? Si oui, quoi?…

Ils augmentent le niveau de garantie que le code que tu télécharge vient bien de l'auteur du code. Il n'y a pas besoin de faire une thèse pour simplement mettre en place une démarche déjà amplement industrialisée.

Aha? Vraiment? Parce que c'est bien connu que Google ne cherche pas à collecter des données personnelles?

Pipy n'est pas Google. Et encore une fois ici la seule info que Google peut avoir c'est de connaître quelle clef privée ils ont envoyé à qui. Ils ne savent pas quel compte pipy l'utilise, ils ne savent pas quand est utilisée, l'authentification ne passe pas par chez eux.

Puisque tu prétends "savoir" ce qu'est un troll, as-tu remarqué que tu me demandes des arguments alors que non seulement tu ne réponds pas à ma question mais qu'en plus tu n'en donnes pas un sur le sujet?

Parce qu'une majorité des arguments consiste simplement à lire la nouvelle, c'est bien pour ça que c'est du troll. Tu as semblé être matrixé par le mot google au point de préférer :

• supposer que le projet pipy vend ses utilisateurs à google dans le plus grand des calmes
• ne pas lire qu'il y a un tas d'autres façons que d'utiliser la clef de google
• de se lancer vite dans une critique avant de se demander ce qu'est TOTP

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

je ne suis perso pas fana des interfaces qui masquent des trucs, même si je peux comprendre le besoin d'une interface qui simplifie les choses ou les rend plus visuel

Ça dépend de pleins de choses, j'utilise beaucoup git en cli, mais pour naviguer dans un historique j'utilise tig ou une interface hors terminal et pour faire des commit patch je fais moins d'erreur avec l'interface de mon ide (même si elle ne peut pas exprimer tout ce qu'on peut faire dans un patch).

Git n'a pas à être le centre de l'usage, il peut très bien être un détail d'implémentation. Surtout si ton besoin c'est prendre un dossier et l'envoyer sur un serveur sans intérêt pour l'historique.

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

Il me semble que si tu utilise une interface qui te cache git et que tu force toutes tes commandes, c'est proche de ce que tu aura avec sftp ou ftps.

Pour éviter l'oublie de pull (que ce soit un pull git ou un get ftp), il faut passer par un répertoire monté comme tu aurait avec webdav ou syncthings.

Je pense que c'est plus la gestion d'état avec le staging par exemple qui doit faire peur. Il me semble que turtoise git voulait avoir le même fonctionnement que turtoise svn et avait caché cet aspect. Mais je l'ai pas revu depuis des années, je sais pas ce qu'il en est.

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

Si on ne veut pas être lu autant écrire son journal intime dans un fichier texte sans se poser plus de questions :p

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

Tu as aussi 2 paquets npm eslint-* qui ont subit ce genre de problème, si j'ai bien compris (il y a 4 ans…).

https://eslint.org/blog/2018/07/postmortem-for-malicious-package-publishes/

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

C'est sûr que si ça passe par G..gl. ça met cette entreprise dans la position d'un état par rapport aux cartes nationales d'identité. Du coup, on peut comprendre ton questionnement et y répondre par le fait qu'ici plusieurs solutions/fournisseurs sont possibles : pas de centralisation G..gl. possible donc, sauf si tout le monde décident de faire ce choix (qui n'est pas imposé par PyPi qu'on s'entende.)

Tu ne peux pas t'authentifier sur pypi avec autre chose qu'un compte pypi (ils n'ont pas de délégation). Si tu utilise une clef d'authentification que ce soit google ou un autre, si j'ai bien compris le fonctionnement, il peut faire le lien entre une clef et toi (il sait à qui il a envoyé quoi), mais il n'a aucun contrôle sur où est-ce que tu t'en sert, avec quel compte, quand, etc.

C'est une info effectivement, mais tu n'y est pas contraint et pypi ne maintiens aucune dépendance envers google. Ils peuvent demain leur dire d'aller se faire cuir un œuf sans que ça ne change quoi que ce soit.

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

La législation parle expressément de la vente de bien immobilier (source : Article 1646-1 du code civil).
Ça ne parait donc pas être un oubli du législateur.

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

Ce n'est pas le cas.

Je suis pas certain que l'antériorité soit recevable s'il a fallut des années de recherche pour trouver la dites failles.

Et de toute manière la gvc dure 5 ans. Intel a cessé de produire des Ivy Bridge en 2015, ils arrêtent leur support en 2020. On pourrait croire qu'ils ont lu la loi.

Si la chose est impropre à l'usage auquel on la destine et que le vice n'était pas apparent, la GVC peut être actionnée (sauf prescription)

Le fait qu'il n'y ai pas eu de rappel de produit me semble aller vers le, ça n'est pas "impropre à l'usage" et tu as 2 ans après l'achat pour l'activer.

Bref ça parait vraiment compliqué amha.

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

Entre les processeurs Intel de 2010 et les derniers AMD, je ne mesure guère qu'un petit facteur 2 à 4 selon les calculs. Pas de quoi balancer les machines.

Sans dire qu'il faut les balancer parce qu'il faut regarder l'ensemble du cycle de vie. Est-ce que tu regarde la puissance de calcul par watt ? Je ne sais pas à quelle point ça s'améliore.

Par ailleurs je me demande dans quelle mesure ces bogues relèves du vice caché, et ne devraient pas être corrigés ?

T'es entrain de dire qu'ils vendent des processeurs avec des failles connues ? C'est pas impossible, mais ça me parait être une très grosse accusation. Et si c'est le cas le support n'est pas le principal point à régler.

D'un point de vue moral, dans la mesure où Intel abandonne le support, ne serait-il pas logique qu'ils libèrent tout le micro-code et les outils de manipulation pour permettre aux clients délaissés de gérer eux-mêmes les problèmes, à défaut d'avoir droit à du support ?

D'un point de vu moral peut être mais il est évident qu'il y a là dedans de la propriété intellectuelle qu'ils continuent d'utiliser dans les CPU suivant. Donc à moins de les contraindre tu n'obtiendra rien.

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

Quelqu'un peut m'expliquer le raisonnement de fond (de Google) selon lequel 2FA réduira (ce que je suppose) la quantité de projets malveillants? Parce que là, je vois vraiment pas le rapport.

Tu ne vois vraiment pas en quoi réduire les risques de vol de compte augmente la sécurité ? Vraiment vraiment ?

En revanche, si Google avait décidé de tout faire pour collecter les informations personnelles et de déployer tous les moyens possible et imaginables pour qu'il soit possible d'identifier avec 100% de certitude une personne (à l'échelle individuelle, donc) en fonction des paramètres collectés, je ne vois pas un meilleur prétexte que la "sécurité"…

On appel ça un procès d'intention. Aujourd'hui tu as ton compte pypi qui n'a pas à être relié à un compte google, le 2FA demande d'avoir une clef d'authentification (tu peut prendre celle qu'ils proposent ou d'autres qui n'ont aucun rapport avec google) ou tu peux utiliser des solutions purement logiciel qui utilisent uniquement du LL comme oathtool.

Mais tout ceci n'est que de la spéculation, n'est-ce pas?

Parfaitement, mais tu as peut être d'autres arguments que "Y A GOOGLE !!!!!".

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

Ruby, TCL ou même PHP sont des vieux langages encore plus poussiéreux et moins puissant que PERL.

Ça se mesure en Watt ? Du coup c'est combien de différence ?

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

Ou des failles indépendantes de la volonté du développeur ou si le développeur est victime d'une suply attack ou si le projet du développeur en question reçoit des contributions malveillantes ou si l'infra du projet est fragile et subit des injections de code par exemple, PyPI eux même pourraient se faire attaquer pour remplacer des paquets par exemple, ça ne résoud pas non plus les faux paquets comme requests vs request…

Il n'y a pas de silver bullet et personne be l'a affirmé. PyPI parle d' améliorer la sécurité rien de plus.

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

D'ailleurs cela laisse entrevoir un autre aspect intéressant de Python: il y a plusieurs implémentations du langage, qui sont adaptées pour différents usages

Oui et non. Ces implémentations n'implémentent que le langage et pas l'API C, ils ont généralement une tambouille pour numpy, mais hors de ça tu n'a pas accès aux bibliothèques qui utilisent du C. On est pas sur un drop in remplacement tel qu'on pourrait s'y attendre. Ensuite micropython implémente pas tout python (toute la bibliothèque standard n'est pas là) et la dernière version est en python 3.4 (avec des bouts de 3.5) version qui a 8 ans et qui est considérée en fin de vie. Pypy supporte jusqu'à 3.7 (version encore supportée upstream) et a une couche de compatibilité pour les bibliothèques qui utilisent du c c'est cool.

Et on pourrait faire la liste comme ça pour chacun. Bref mon point c'est qu'il s'agit pas d'implémentations où tu change la stack et c'est parti. Tu code généralement en sachant quelle implementation tu va utiliser c'est très différent comme approche.

---

Après quant à perl vs python, il faut comprendre qu'une grande partie du succès ou non ne vient pas d'une valeur intrinsèque. Perl, ruby, python sont 3 très bons languages sinon on en parlerai plus 25 ans après leur apparition. Il se fait qu'actuellement c'est python qui semble de loin le plus populaire, mais ça n'est pas une raison pour tuer les autres.

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

Contrairement à une idée très répandue le brainfuck est pas très compliqué. Par contre le moins connu malbolge est de très loin le langage le plus complexe que j'ai pu voir.

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

Pour ce qui est de la quantité de trucs configurables, le about:config de firefox, il existe aussi chez les autres hein (sauf que ça a un nom plus adapté: about:flags).

Je ne sais pas pour les autres mais sur Firefox ce ne sont pas des flags.

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