barmic 🦦 a écrit 5976 commentaires

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

Par contre je me demande comment je vais réussir à faire travailler X développeurs ensemble, et comment je peux trouver les compétences pour. Or sur ces deux plans Perl perds.

Je suis partiellement d'accord. Parce que c'est une donnée qui varie selon les équipes, ça.

Ah noter que dans un avenir proche tous les bacheliers ou tous les bacheliers scientifiques auront eu une formation initiale en python.

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

C'est loin d'être le seul langage comme ça. C++, lisp, scala, groovy,… sont peut être encore plus souples.

Ce qui fait mal à perl, c'est la popularité de python. Elle fait presque aussi mal à ruby. Les 3 langages de scripts qui se valaient il y a 20 ans, aujourd'hui python les a largement dépassé en terme de popularité. C'est une sorte d'effet boule de neige.

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

Je comprends pas l'argument.

Dans l'avenir l'authentification multi facteur va devenir la norme dans tout ce qui est critique en premier puis partout quand on se rendra compte que tout est critique. C'est pas une question d'entreprise. Ta banque et tous les endroits où tu met de l'argent (tout ce qui est paiement en ligne), tous les endroits qui représentent trop ton identité (ton compte mail et les réseau sociaux si tu es une personne publique).

Dans l'avenir les gens auront eu affaire à ce genre de mécanisme avant d'avoir connu le monde de l'entreprise. Je vois pas pourquoi ils ferraient le lien. En fait je vois même pas en quoi le fait que ça puisse ressembler à ton travail pose problème. Coder, commiter, gérer des bugs,… c'est le travail de pleins de gens dont le hobby est aussi de participer à du code libre.

On aurait pu dire la même chose pour l'utilisation de mot de passe, de nom de domaine, de tls,…

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

L'argumentaire est intéressant : je donne déjà de mon temps pour dev un projet, svp pas de poids en plus pour moi, je fais ça pour le plaisir. Et si une entreprise repose sur mon taf et a besoin de propriétés "sécu" qu'elle n'hésite pas à me contacter.

Moi je pense que c'est un véritable problème. Ce mécanisme de pypi n'est que la conséquence de quelque chose qui est déjà présent et qui ne change pas avec le fait que tu détruit et reconstruit ton package (je doute que pypi ne réagisse pas à ça au bout d'un moment). La popularité de ton code donne de facto une criticité plus importante à ton projet. Et ce même si aucune entreprise n'est dans la boucle.

Tu parle de s'attaquer au compteur mais c'est pas le fond du problème.

Et c'est aujourd'hui juste pour les 1% les plus populaire, mais je ne serais pas surpris que ça devienne la règle inconditionnelle (comme le fait github).

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

Je ne sais pas ce qu'il fait, mais on peut envisager :

• utiliser 2 fichiers de base de données différents avec un déchiffrement différent sur chacun
• utiliser un fichier de clef pour le déchiffrer, il te faut le fichier et la passe phrase de ce fichier pour y accéder

Est-ce que ça reste pas plus faible qu'un OTP distinct je ne sais pas.

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

Je ne sais pas si tu as encore le problème, mais connaissant apt je serais surpris que tu ne puisse pas ajouter ton propre script à lancer systématiquement après update-grub (ou faire en sort que grub-install applique ta configuration). En dernier recours peut être qu'un apt-divert permettrait de ne pas écraser ta config.

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

Ceci dit, je ne rappelais pas la bonne volonté pour taper sur ce corps de métier mais juste qu'il ne faut pas oublier cet aspect de l'équation (on a partout des gens supers, des gens plein de méchanceté gratuite ou de suspicions, des gens qui font du zèle, des gens qui ont la flemme, de tout.)

J'avoue ne pas comprendre la démarche. À chaque fois que tu vois quelqu'un parler de remonter un bug, il faut (c'est un besoin) lui répondre spécifiquement pour lui rappeler que la correction sera à la bonne volonté du développeur par exemple ?

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