Les gens qui ont paniqué à l’idée d’une rupture d’approvisionnement ponctuelle vont sans aucun doute réagir de manière rationnelle, calme et pondérée à l’idée d’une rupture d’approvisionnement définitive.
et je fais quasiment tous mes déplacements à vélo (électrique) quasiment 15 km par jour (boulangerie, commerces de bouches, bibliothèque, piscine, loisirs etc.). Je n’utilise la voiture presque que pour mon aller-retour hebdomadaire à Paris (40 km pour aller à la gare) ou certains achat volumineux. Si mon boulot était sur place, je n’aurais presque pas besoin de voiture.
« Quasiment ». « Presque que ». « Presque pas besoin » (et encore, « si le boulot était sur place », donc il faut conclure que comme ton boulot n’est pas sur place, en fait tu as bien complètement besoin de ta bagnole).
Donc maison individuelle = voiture est une exagération qui cherche à clore le débat, mais largement infondée.
C’est cela, oui…
De mon côté et « pour information », je vis en appartement en ville depuis le début, je n’ai pas de voiture et je n’en ai jamais eu besoin. Je me déplace à pieds ou en transports en commun.
Je n’ai peut-être mon propre jardin à cultiver ou « accès à la terre et au ciel », mais j’ai la prétention de faire moins de dégâts que quelqu’un qui prétend « aimer la nature et être proche d’elle » tout en prenant leur voiture tous les jours pour aller bosser, voire pour aller chercheur leurs croissants au village d’à côté (ce qui est le cas d’au moins 80% de mes connaissances qui vivent en maison à la campagne ; oui, c’est une estimation personnelle qui ne vaut pas grand’chose, tout comme ton « largement infondée »).
Par chez moi, il n’existe pas de « zone ». C’est un problème inhérent aux grandes villes. C’est l’aberration sociale, toujours éludée des grands ensembles.
Ouais, mieux vaut émettre 10t de CO₂ à la campagne en compagnie de gens bien comme nous que 4t en ville à vivre près de ces autres gens…
Donc ils vont faire quoi ? Attendre 2026 pour tenter tant bien que mal de faire une migration 13 versions ?
Ils sont au courant de la nécessité de migrer, merci pour eux Monsieur Yakafocon.
La migration a déjà commencé sur des branches dédiées, mais ce n’est pas (encore) prêt à être intégré à la branche principale, notamment parce que ça n’a pas encore été suffisamment testé.
Et c'est à ce moment là qu'ils vont rugir que vraiment la compatibilité de java c'est pas top ?
Tu ne les as pas entendu se plaindre de la compatibilité de Java, que je sache ?
Je ne m’en suis pas plaint non plus d’ailleurs : quelqu’un a demandé des examples concrets de programmes cassés par l’évolution de Java au cours du temps, j’en ai donné, c’est tout. Non pas parce pour me plaindre que Java c’est de la merde pas rétrocompatible, mais pour souligner que sa rétrocompatibilité n’a rien d’exceptionnel, en réponse à ceux qui le prétendaient (ce qui est ridicule : Java a des avantages bien réels, nul besoin d’inventer des avantages fantaisistes).
je n'utilise pas leur logiciel, je ne connaît pas toute leur problématique […] mais à mon humble avis la vie d'apparente insouciance risque fort dans une certaine douleur.
C’est ça, oui, là pour l’instant ils se tournent les pouces en se disant « bouarf, on s’en occupera plus tard, tranquille ».
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.
Si tu ne veux un programme qui ne fonctionne qu’en mode console, peut-être.
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 ?
Le choix de Java a permis d’avoir un programme dont le développement a commencé à la fin des années 1990 de tourner en mode graphique sous Windows, Mac OS, GNU/Linux (et à l’époque aussi Solaris, HP-UX, AIX, et quelques autres), et de continuer à tourner plus de vingt ans plus tard.
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.
C'est quelque chose à prendre en compte.
Certes, mais c’est loin d’être la seule chose à prendre en compte, et à mon sens pas la plus importante.
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
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
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.
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.
Je suis complètement d’accord avec ça. 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 ?
Je me permet aussi d'émettre un doute sur la qualité du code de Protégé : le fichier de démarrage force la taille de la pile à 16 Mo (!) par défaut, ce qui est gigantesque et extrêmement inhabituel.
De mémoire c’était à cause d’un plugin C++, le reasonerFaCT++, qui pour je ne sais quelle raison avait besoin d’une pile plus grande. Protégé lui-même et les reasoners écrit en pure Java (comme ELK ou HermiT) se satisfont très bien de la taille de la pile par défaut.
Voir quelque chose d’inhabituel et en émettre d’emblée des doutes sur la qualité du code sans rien savoir de l’historique et des raisons derrière… Mouais bof.
Ben, euh, sur quatre programmes Java que j’utilise régulièrement :
Protégé ne fonctionne qu’avec Java8 (toute tentative de le lancer avec une version ultérieure se solde par un crash immédiat) ;
ImageJ, même chose, c’est Java8 et rien d’autre (et avant ça il ne fonctionnait qu’avec Java6, le passage à Java8 avait été laborieux) ;
OMERO ne fonctionne qu’avec Java11, et il y a encore peu c’était uniquement Java8 ;
Freeplane ne fonctionne avec Java17 que depuis quelques mois seulement.
Alors peut-être que ce ne sont que des exceptions et que je n’ai vraiment pas de bol à ne devoir utiliser que des programmes exceptionnels, mais en attendant, quand j’entends parler de la rétro-compatibilité de Java, je rigole jaune en pensant aux trois JRE différents (8, 11, et 17) que je suis obligé d’avoir sur ma machine…
OK, je viens de comprendre. Dans le contexte de la discussion j’ai cru que c’était le principe de l’enrôlement de machine que tu critiquais, au profit de la seule authentification à deux facteurs. My bad.
Je partage ton point de vue concernant le téléphone. Mes seconds facteurs ne sont pas stockés sur mon téléphone, sur lequel par principe je stocke le minimum d’information possible, et surtout pas des clefs ou des mots de passe (les seuls mots de passe enregistrés sur mon téléphone sont des jetons spécifiques à ce périphérique, révocables à tout moment).
Tout ça c’est bien joli, mais à ma connaissance l’enrôlement de la machine sur laquelle tu utilises twine est le seul moyen de pouvoir continuer à utiliser twine une fois que tu as activé l’authentification à deux facteurs. La vérification du second facteur n’est pas possible avec l’API !
Refuser de permettre l’enrôlement de machine sur PyPI, au motif que tu affaiblirais la sécurité en introduisant un maillon soi-disant plus faible, ce serait conduire tous les utilisateurs qui le peuvent (c’est-à-dire, tous sauf ceux responsables du 1% de projets « critiques » qui n’ont désormais plus le choix) à rejeter purement et simplement l’authentification à deux facteurs, parce qu’elle rend l’outil de téléchargement de paquets tout simplement inutilisable…
Et ce n’est pas valable que pour PyPI. C’est la même histoire chaque fois que tu as besoin qu’un outil se connecte à un compte de manière non-interactive (incompatible avec le besoin de vérifier un second facteur, qui quasiment par définition impose une interaction avec le titulaire du compte).
Je n’aurais jamais activé l’authentification à deux facteurs sur mes comptes mails si je n’avais pas pu, dans le même temps, enrôler ma machine qui fait tourner un démon fetchmail pour automatiquement collecter mes mails depuis tous mes comptes. Je n’aurais jamais activé l’authentification à deux facteurs sur mon compte Nextcloud si je n’avais pas pu enrôler toutes les différentes machines sur lesquelles je veux que mes contacts, agenda, photos, etc. soient synchronisés en arrière-plan.
C’est pour ça que l’enrôlement de machine n’est pas une alternative à l’authentification à deux facteurs, et encore moins un « maillon plus faible ». Bien au contraire, c’est ce qui rend l’authentification à deux facteurs possible au-delà du cas basique de l’utilisateur devant un navigateur web (qui est, faut-il le rappeler, juste une petite facette de l’Internet).
Pourquoi pas les deux ? Authentification à deux facteurs et enrôlement de la machine ?
C’est justement ce que fait PyPI. Tu peux avoir une authentification à deux facteurs (que ce soit via une application TOTP ou via une clef FIDO U2F) pour te connecter à ton compte PyPI et utiliser un jeton (token) propre à chaque machine pour télécharger des paquets sur le serveur via l’API.
Le jeton te permet d’utiliser l’API de PyPI indépendamment de ton mot de passe (et de l’authentification à deux facteurs qui y est éventuellement associée) et a plusieurs avantages par rapport à un mot de passe :
ce qu’il est possible de faire avec le jeton est limité ; en gros, tu ne peux que t’en servir pour télécharger des paquets vers PyPI via l’API, il ne donne pas accès au compte lui-même (en particulier, il ne permet donc pas de changer le mot de passe du compte, ou de générer/révoquer des jetons) ;
tu peux même limiter encore plus le « rayon d’action » du jeton, en le limitant à un projet précis ;
le jeton peut être révoqué à tout moment, sans aucun effet sur ton mot de passe et ton second facteur.
Du coup, il devient acceptable de faire avec le jeton ce qu’il ne faut jamais faire avec un mot de passe, à savoir l’écrire quelque part dans un fichier de configuration — typiquement, le fichier de configuration de twine, utilisé pour télécharger des paquets vers PyPI depuis la ligne de commande.
Ça te permet donc de télécharger des paquets aussi souvent que tu en as besoin sans jamais avoir besoin de saisir ni mot de passe ni code de vérification. Si jamais ta machine venait à être compromise, il te suffit de te connecter à ton compte via l’interface web (où là tu auras besoin de ton mot de passe et du second facteur associé) et de révoquer le jeton incriminé.
Avec cette configuration, la « pénibilité » de l’authentification à deux facteurs est considérablement réduite, puisque j’ai beaucoup plus souvent besoin de télécharger un paquet via twine (ce qui ne nécessite aucun mot de passe, le jeton est suffisant) que de me connecter à mon compte sur PyPI (la dernière fois que j’ai eu à faire ça, c’était justement pour générer un nouveau jeton pour enrôler une nouvelle machine).
On a des cas de contributeurs à PyPI ou à NPM dont les mots de passe ont été captés par des acteurs malveillants qui les ont ensuite utilisé pour publier du code malveillant au nom de ces contributeurs ?
Je me réponds tout seul : il y a uncas documenté, un attaquant a pris le contrôle du compte responsable du paquet ctx (manifestement abandonné depuis plusieurs années), en profitant du fait que le titulaire du compte avait laissé son nom de domaine expirer (permettant à l’attaquant de récupérer le nom de domaine, et partant de recevoir le mail de réinitialisation de mot de passe).
Il me semble probable que ce soit ce cas précis, survenu il y a quelque mois à peine, qui ait décidé les responsables de PyPI à forcer l’utilisation de l’authentification à deux facteurs, bien plus que l’étude de la OpenSSF qui concerne un problème complètement différent.
Mais un cas, donc. On reste loin du « on a eu beaucoup de cas qui font que ce scénario n'est plus de faible probabilité mais avéré ».
quand une personne malveillante arrive à capter le mot de passe d'une autre personne bienveillante, malveillante peut commettre des exactions au nom de bienveillante ; et malheureusement on a eu beaucoup de cas qui font que ce scénario n'est plus de faible probabilité mais avéré
[Référence nécessaire]
On a des cas de contributeurs à PyPI ou à NPM dont les mots de passe ont été captés par des acteurs malveillants qui les ont ensuite utilisé pour publier du code malveillant au nom de ces contributeurs ?
La dépêche fait référence (sans lien d’ailleurs, ce qui est dommage) à une étude de l’Open Source Security Foundation qui a trouvé « plus de 200 paquets Javascript et Python malveillant ». Il s’agit de ce projet, dont le résumé dit clairement
The vast majority of the malicious packages we detected are dependency confusion and typosquatting attacks.
(L’emphase est de moi.) Les attaques par « confusion de dépendances¹ » et « typosquattage » ne nécessitent aucunement de capturer les identifiants et mots de passe de qui que ce soit. L’attaquant publie les paquets malveillants avec un compte qu’il a créé lui-même et donc qu’il contrôle déjà entièrement. C’est justement un des intérêts de ces attaques que de ne pas nécessiter un quelconque acte de « piraterie » pour être mis en œuvre.
L’authentification à deux, trois, ou douze facteurs n’a strictement aucun effet sur ce genre d’attaques.
L’étude ne mentionne explicitement aucun cas de code malveillant publié avec le compte d’un contributeur légitime qui se serait fait pirater son compte. Je pense que s’ils avaient détecté un tel cas, ç’aurait été suffisamment notable pour mériter une mention.
Donc non, il n’y a pas de rapport entre « tout le monde peut publier sur NPM ou PyPI, du coup il y a des paquets malveillants » et « désormais les projets critiques doivent utiliser l’authentification à deux facteurs ». Le second n’est pas une solution au premier, c’est une solution à un tout autre problème,² et jusqu’à preuve du contraire un problème beaucoup moins répandu que le premier.
¹ En gros, l’attaquant apprend, d’une manière ou une autre, que la cible utilise des paquets PyPI ou NPM privés (hébergés sur un dépôt interne), et du coup publie un paquet avec le même nom sur PyPI ou NPM, ce qui « masque » les paquets hébergés sur le dépôt privé et conduit la victime à télécharcher le paquet fabriqué par l’attaquant plutôt que le paquet hébergé en interne.
² Non pas que ce soit une mauvaise solution (perso j’accueille favorablement toute initiative en faveur de la généralisation de l’authentification à deux facteurs, que j‘utilise moi-même partout où elle est disponible, y compris sur PyPI).
Bah c’est un truc basé sur Electron, hein. C’est pas un éditeur de texte, c’est un navigateur web qui exécute du Javascript pour se comporter comme un éditeur de texte.
Le but de construire une application sur Electron est que ce soit rapide à mettre en place quand on a principalement des développeurs web sous la main (et qu’on ne veut pas recruter des développeurs qui connaissent autre chose), pas que ce soit rapide à l’exécution. D’façon, tout le monde a 32 Go de RAM sur sa machine aujourd’hui, non ?
l'entropie n'augmente pas avec le nombre d'itérations.
Personne n’a prétendu le contraire.
les itérations ne servent alors qu'à cacher la misère. à donner aux données une apparence de nombre aléatoire
Pas du tout. On ne compte pas sur le nombre d‘itérations pour « donner aux données une apparence de nombre aléatoire » (ça voudrait dire quoi d’ailleurs ?).
Le nombre d’itérations ne sert pas à augmenter l’entropie, mais à compenser la faible entropie de départ en rendant plus difficile de réaliser une attaque par force brute.
Parce que le problème des mots de passe, c’est justement qu’ils sont vulnérables aux attaques par force brute (contrairement à une suite d’octets aléatoires provenant d’un RNG). Un mot de passe de 8 caractères alphanumériques par exemple, c’est au maximum (26 + 26 + 10)⁸ possibilités. C‘est largement à la portée des machines modernes, qui peuvent calculer plusieurs milliards de condensats SHA2-256 par seconde.
(Et encore, là je ne tiens pas compte de plusieurs facteurs qui rendent les attaques encore plus faisables, comme le fait que les humains sont notooirement très mauvais quand il s’agit de choisir un mot de passe – ce que les craqueurs de mots de passe savent très bien exploiter, notamment en faisant des attaques par dictionnaire plutôt que d’énumérer bêtement toutes les combinaisons de caractères possibles.)
Du coup, puisque le nombre de possibilités à tester est relativement faible (suffisamment faible pour être brute-forceable), on augmente le nombre d’itérations pour que chaque possibilité à tester prenne plus longtemps. Avec 1 000 itérations, une machine capable de calculer un milliard de condensats SHA2-256 par seconde ne peut plus tester qu’un million de possibilités par seconde.
C’est à ça, et uniquement à ça, que sert le nombre d’itérations.
il vaut mieux mettre en place un système d'accumulation d'entropie et ne faire qu'un hash en sortie plutôt que le système décrit dans ce document..
C’est quoi que tu ne comprends pas dans le fait qu’ici l’entrée de la fonction est un mot de passe entré par l’utilisateur ?
Tu ne peux pas ajouter de l’entropie à un mot de passe ! Ta fonction de dérivation doit se débrouiller avec le mot de passe choisi par l’utilisateur.
je maintiens que la fonction SHA256 est cryptographiquement assez bonne pour générer en une passe.
Lorsque l‘entrée est une suite d’octets (pseudo-)aléatoire (par exemple une graine en provenance directe d‘un RNG), oui. Lorsque l’entrée est un mot de passe, catégoriquement pas.
Le problème n’est pas que SHA2-256 n’est pas « cryptographiquement assez bonne » (elle l’est), le problème est qu’elle est rapide.
le document me laisse un peu songeur étant donné qu'il conseille l'utilisation du SHA-1 comme PRF qui ne doit plus être utilisé dans les systèmes modernes.
L’absence de résistance aux collisions n’a absoluement aucune importance ici.
Fun fact : la principale raison pour laquelle on veut se débarasser complètement de SHA-1 est que les cryptologues ont en assez de devoir expliquer constamment que non, toutes les applications cryptographiques des fonctions de condensation n’ont pas forcément besoin de la propriété de résistance aux collisions.
donc pour moi, je persiste il n'y a aucun souci à utiliser le SHA256 en une instance.
Si, parce qu’ici l’entrée de la KDF est un mot de passe, dont l’entropie est incertaine et toujours considérée comme significativement plus faible qu‘une suite d’octets aléatoires de même longueur.
La fiabilité de la fonction de condensation ne te sauvera pas si l‘attaquant peut brute-forcer ton mot de passe — ce qui ne pose aucune difficulté si la fonction de dérivation ne consiste qu‘en un unique appel à une fonction extrêmement rapide comme SHA2-256.
Ici, on n’a pas besoin d’une Key Derivation Function tout court mais d’une Password-Based Key Derivation Function (PBKDF), qui prend précisément en compte la faible entropie du mot de passe d’entrée.
Du coup ce n’est pas le NIST SP800-108 qu’il faut consulter, mais le NIST SP800-132, qui recommande au minimum 1 000 itérations.
Je n’aime pas écrire ce commentaire, parce que je ne veux pas « descendre » un projet libre partagé « dans l’espoir qu’il sera utile ».
Mais en l’état, je me dois de déconseiller l’utilisation de ce logiciel excepté dans les situations où la menace est quasiment inexistante — autrement dit, si vous ne voulez que stocker vos identifiants sans aucunement chercher à les protéger.
La première phrase de la dépêche dit tout :
Ce logiciel de gestion de mots de passe a été développé au départ pour une utilisation personnelle et aussi dans un but didactique pour mieux appréhender les fonctions de cryptographie.
Il n’y a bien sûr aucun mal à créer un logiciel dans un but didactique et ce n’est sûrement pas quelque chose qui doit être découragé, bien au contraire.
Mais du côté des utilisateurs potentiels, il faut être conscient de ce que ça implique. En l’occurrence ici, que la protection cryptographique semble reposer sur des bases fragiles.
Un rapide coup d’œil au code montre (au moins, pas tout regardé en détail) deux gros red flags :
une implémentation personnelle d’AES (aka rolling your own crypto), au lieu d’utiliser une bibliothèque cryptographique éprouvée — certes ça se justifie dans un but didactique, mais pas pour un logiciel proposé à l’utilisation (c’est une violation du Foot-Shooting Prevention Agreement que tout développeur apprenant AES devrait normalement signer ;) ) ;
la clef principale est dérivée du master password par une simple condensation SHA2-256 :
// définir key et iv pour AES cbc// key est calculé à partir du master password saisi par l'utilisateurQByteArraycombined=getMasterPassword().toLatin1();QByteArrayhashed=QCryptographicHash::hash(combined,QCryptographicHash::Sha256);hashed=hashed.toHex().toBase64();hashed=hashed.replace('+','A').replace('/','B').replace('=','C');key=hashed.simplified().left(64);
C’était acceptable il y a vingt ans, ça… Aujourd’hui l’état de l’art commande d’utiliser des primitives cryptographiques spécialement conçues pour la dérivation de clef. Au minimum PBKDF2, ou mieux encore de nos jours les fonctions de la famille Argon2.
L'essentiel du spam que je reçois provient des très gros, et en particulier Exchange et Gmail.
Observation similaire de mon côté. Les proportions varient d‘un mois à l’autre et il y a clairement des « vagues », mais les comptes Hotmail et GMail représentent toujours une part significative du spam (à la louche je dirais de 25% pendant les périodes « calmes » à plus de 70% pendant les « vagues »).
SMTP DANE (DNS-based Authentication of Named Entities) est une méthode permettant d’authentifier un serveur de courrier électronique via des clefs publiques ou des certificats X.509 publiés dans le DNS. Longtemps négligée par les « gros acteurs » (et activement combattue par Google, comme tout ce qui repose sur le DNS plutôt que des solutions à base de web), cette méthode vient d’être adoptée (dans un sens seulement, pour l’instant) par Microsoft pour Exchange Online : désormais, lors de l’envoi d’un e-mail depuis Exchange Online, le serveur vérifiera la présence d’enregistrements TLSA dans le domaine du destinataire, et agira en conséquence (en refusant par exemple de procéder à l’envoi si le serveur du destinataire présente un certificat ne correspondant pas à un des enregistrements TLSA).
L’adoption dans l’autre sens, c’est-à-dire la publication des clefs publiques ou certificats des serveurs Exchange dans le DNS, de sorte qu’un serveur devant envoyer un e-mail à un destinataire utilisant Exchange puisse authentifier les serveurs Exchange préalablement à l’envoi, est annoncée pour fin 2022.
Compte tenu du poids d’Exchange, notamment en milieu professionnel, c’est une très bonne nouvelle pour SMTP DANE et pour le chiffrement généralisé des e-mails en transit.
Vérifie si less utilise un préprocesseur, c’est peut-être ce préprocesseur qui affiche ce message. As-tu une variable LESSOPEN dans ton environnement, et si oui que contient-elle ?
Sais-tu si des gens commencent à travailler à traiter correctement cette difficulté ?
Aucune idée. Le truc le plus récent que je connaisse date du début du siècle, je doute fort que ça fonctionne encore.
Le truc qui s’en rapproche le plus, aujourd’hui et à ma connaissance, c’est le standard W3C Subresource Integrity, qui permet d’indiquer qu’un script Javascript doit avoir un certain condensat pour être autorisé à s’exécuter :
Mais comme le condensat est fourni par le même site qui demande l’exécution du code Javascript, ça ne protège absolument pas contre le cas de figure où c’est ce site qui est malveillant (si c’était une signature et non un condensat, ça protégerait au moins contre le cas où un pirate prend le contrôle du serveur… à condition que la clef de signature ne soit pas sur le même serveur, sinon le pirate en prend le contrôle aussi et peut ré-émettre des signatures à sa guise).
C’est surtout conçu pour les cas où les fichiers Javascript sont hébergés ailleurs que sur le serveur du site, typiquement sur un CDN. Ça protège contre un CDN malveillant ou contre une attaque entre le CDN et le client, mais pas contre un serveur malveillant.
[^] # Re: Bernard et son avion
Posté par gouttegd . En réponse au journal Hypocrisie d'énergie . Évalué à 8.
Ah, bon bah tout va bien alors.
Les gens qui ont paniqué à l’idée d’une rupture d’approvisionnement ponctuelle vont sans aucun doute réagir de manière rationnelle, calme et pondérée à l’idée d’une rupture d’approvisionnement définitive.
[^] # Re: Bernard et son avion
Posté par gouttegd . En réponse au journal Hypocrisie d'énergie . Évalué à 6.
Et la capacité des gens à supporter la moindre pénurie de quoi que ce soit — ou même la possibilité d’une pénurie…
Tout le monde a déjà oublié les scènes du printemps 2020, lorsque des magasins se sont trouvés temporairement à court de PQ ?
[^] # Re: Petits gestes et grand vide
Posté par gouttegd . En réponse au journal Hypocrisie d'énergie . Évalué à 6.
« Quasiment ». « Presque que ». « Presque pas besoin » (et encore, « si le boulot était sur place », donc il faut conclure que comme ton boulot n’est pas sur place, en fait tu as bien complètement besoin de ta bagnole).
C’est cela, oui…
De mon côté et « pour information », je vis en appartement en ville depuis le début, je n’ai pas de voiture et je n’en ai jamais eu besoin. Je me déplace à pieds ou en transports en commun.
Je n’ai peut-être mon propre jardin à cultiver ou « accès à la terre et au ciel », mais j’ai la prétention de faire moins de dégâts que quelqu’un qui prétend « aimer la nature et être proche d’elle » tout en prenant leur voiture tous les jours pour aller bosser, voire pour aller chercheur leurs croissants au village d’à côté (ce qui est le cas d’au moins 80% de mes connaissances qui vivent en maison à la campagne ; oui, c’est une estimation personnelle qui ne vaut pas grand’chose, tout comme ton « largement infondée »).
Ouais, mieux vaut émettre 10t de CO₂ à la campagne en compagnie de gens bien comme nous que 4t en ville à vivre près de ces autres gens…
[^] # Re: C'est moi ou c'est idiot ?
Posté par gouttegd . En réponse au journal Google forke C++. Évalué à 5.
Ils sont au courant de la nécessité de migrer, merci pour eux Monsieur Yakafocon.
La migration a déjà commencé sur des branches dédiées, mais ce n’est pas (encore) prêt à être intégré à la branche principale, notamment parce que ça n’a pas encore été suffisamment testé.
Tu ne les as pas entendu se plaindre de la compatibilité de Java, que je sache ?
Je ne m’en suis pas plaint non plus d’ailleurs : quelqu’un a demandé des examples concrets de programmes cassés par l’évolution de Java au cours du temps, j’en ai donné, c’est tout. Non pas parce pour me plaindre que Java c’est de la merde pas rétrocompatible, mais pour souligner que sa rétrocompatibilité n’a rien d’exceptionnel, en réponse à ceux qui le prétendaient (ce qui est ridicule : Java a des avantages bien réels, nul besoin d’inventer des avantages fantaisistes).
C’est ça, oui, là pour l’instant ils se tournent les pouces en se disant « bouarf, on s’en occupera plus tard, tranquille ».
[^] # Re: C'est moi ou c'est idiot ?
Posté par gouttegd . En réponse au journal Google forke C++. Évalué à 4.
Je ne crois pas, non.
Si tu ne veux un programme qui ne fonctionne qu’en mode console, peut-être.
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 ?
Le choix de Java a permis d’avoir un programme dont le développement a commencé à la fin des années 1990 de tourner en mode graphique sous Windows, Mac OS, GNU/Linux (et à l’époque aussi Solaris, HP-UX, AIX, et quelques autres), et de continuer à tourner plus de vingt ans plus tard.
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.
Certes, mais c’est loin d’être la seule chose à prendre en compte, et à mon sens pas la plus importante.
[^] # Re: C'est moi ou c'est idiot ?
Posté par gouttegd . En réponse au journal Google forke C++. Évalué à 4.
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
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.
Je suis complètement d’accord avec ça. 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 ?
[^] # Re: C'est moi ou c'est idiot ?
Posté par gouttegd . En réponse au journal Google forke C++. Évalué à 3.
De mémoire c’était à cause d’un plugin C++, le reasoner FaCT++, qui pour je ne sais quelle raison avait besoin d’une pile plus grande. Protégé lui-même et les reasoners écrit en pure Java (comme ELK ou HermiT) se satisfont très bien de la taille de la pile par défaut.
Voir quelque chose d’inhabituel et en émettre d’emblée des doutes sur la qualité du code sans rien savoir de l’historique et des raisons derrière… Mouais bof.
[^] # Re: C'est moi ou c'est idiot ?
Posté par gouttegd . En réponse au journal Google forke C++. Évalué à 5.
Ben, euh, sur quatre programmes Java que j’utilise régulièrement :
Alors peut-être que ce ne sont que des exceptions et que je n’ai vraiment pas de bol à ne devoir utiliser que des programmes exceptionnels, mais en attendant, quand j’entends parler de la rétro-compatibilité de Java, je rigole jaune en pensant aux trois JRE différents (8, 11, et 17) que je suis obligé d’avoir sur ma machine…
[^] # Re: Mauvais facteur
Posté par gouttegd . En réponse à la dépêche PyPI déploie le système 2FA pour les projets critiques écrits en Python. Évalué à 3.
OK, je viens de comprendre. Dans le contexte de la discussion j’ai cru que c’était le principe de l’enrôlement de machine que tu critiquais, au profit de la seule authentification à deux facteurs. My bad.
Je partage ton point de vue concernant le téléphone. Mes seconds facteurs ne sont pas stockés sur mon téléphone, sur lequel par principe je stocke le minimum d’information possible, et surtout pas des clefs ou des mots de passe (les seuls mots de passe enregistrés sur mon téléphone sont des jetons spécifiques à ce périphérique, révocables à tout moment).
[^] # Re: Mauvais facteur
Posté par gouttegd . En réponse à la dépêche PyPI déploie le système 2FA pour les projets critiques écrits en Python. Évalué à 2.
Tout ça c’est bien joli, mais à ma connaissance l’enrôlement de la machine sur laquelle tu utilises twine est le seul moyen de pouvoir continuer à utiliser twine une fois que tu as activé l’authentification à deux facteurs. La vérification du second facteur n’est pas possible avec l’API !
Refuser de permettre l’enrôlement de machine sur PyPI, au motif que tu affaiblirais la sécurité en introduisant un maillon soi-disant plus faible, ce serait conduire tous les utilisateurs qui le peuvent (c’est-à-dire, tous sauf ceux responsables du 1% de projets « critiques » qui n’ont désormais plus le choix) à rejeter purement et simplement l’authentification à deux facteurs, parce qu’elle rend l’outil de téléchargement de paquets tout simplement inutilisable…
Et ce n’est pas valable que pour PyPI. C’est la même histoire chaque fois que tu as besoin qu’un outil se connecte à un compte de manière non-interactive (incompatible avec le besoin de vérifier un second facteur, qui quasiment par définition impose une interaction avec le titulaire du compte).
Je n’aurais jamais activé l’authentification à deux facteurs sur mes comptes mails si je n’avais pas pu, dans le même temps, enrôler ma machine qui fait tourner un démon fetchmail pour automatiquement collecter mes mails depuis tous mes comptes. Je n’aurais jamais activé l’authentification à deux facteurs sur mon compte Nextcloud si je n’avais pas pu enrôler toutes les différentes machines sur lesquelles je veux que mes contacts, agenda, photos, etc. soient synchronisés en arrière-plan.
C’est pour ça que l’enrôlement de machine n’est pas une alternative à l’authentification à deux facteurs, et encore moins un « maillon plus faible ». Bien au contraire, c’est ce qui rend l’authentification à deux facteurs possible au-delà du cas basique de l’utilisateur devant un navigateur web (qui est, faut-il le rappeler, juste une petite facette de l’Internet).
[^] # Re: Mauvais facteur
Posté par gouttegd . En réponse à la dépêche PyPI déploie le système 2FA pour les projets critiques écrits en Python. Évalué à 5.
Pourquoi pas les deux ? Authentification à deux facteurs et enrôlement de la machine ?
C’est justement ce que fait PyPI. Tu peux avoir une authentification à deux facteurs (que ce soit via une application TOTP ou via une clef FIDO U2F) pour te connecter à ton compte PyPI et utiliser un jeton (token) propre à chaque machine pour télécharger des paquets sur le serveur via l’API.
Le jeton te permet d’utiliser l’API de PyPI indépendamment de ton mot de passe (et de l’authentification à deux facteurs qui y est éventuellement associée) et a plusieurs avantages par rapport à un mot de passe :
Du coup, il devient acceptable de faire avec le jeton ce qu’il ne faut jamais faire avec un mot de passe, à savoir l’écrire quelque part dans un fichier de configuration — typiquement, le fichier de configuration de twine, utilisé pour télécharger des paquets vers PyPI depuis la ligne de commande.
Ça te permet donc de télécharger des paquets aussi souvent que tu en as besoin sans jamais avoir besoin de saisir ni mot de passe ni code de vérification. Si jamais ta machine venait à être compromise, il te suffit de te connecter à ton compte via l’interface web (où là tu auras besoin de ton mot de passe et du second facteur associé) et de révoquer le jeton incriminé.
Avec cette configuration, la « pénibilité » de l’authentification à deux facteurs est considérablement réduite, puisque j’ai beaucoup plus souvent besoin de télécharger un paquet via twine (ce qui ne nécessite aucun mot de passe, le jeton est suffisant) que de me connecter à mon compte sur PyPI (la dernière fois que j’ai eu à faire ça, c’était justement pour générer un nouveau jeton pour enrôler une nouvelle machine).
[^] # Re: Je vois pas le rapport!
Posté par gouttegd . En réponse à la dépêche PyPI déploie le système 2FA pour les projets critiques écrits en Python. Évalué à 7.
Je me réponds tout seul : il y a un cas documenté, un attaquant a pris le contrôle du compte responsable du paquet
ctx(manifestement abandonné depuis plusieurs années), en profitant du fait que le titulaire du compte avait laissé son nom de domaine expirer (permettant à l’attaquant de récupérer le nom de domaine, et partant de recevoir le mail de réinitialisation de mot de passe).Il me semble probable que ce soit ce cas précis, survenu il y a quelque mois à peine, qui ait décidé les responsables de PyPI à forcer l’utilisation de l’authentification à deux facteurs, bien plus que l’étude de la OpenSSF qui concerne un problème complètement différent.
Mais un cas, donc. On reste loin du « on a eu beaucoup de cas qui font que ce scénario n'est plus de faible probabilité mais avéré ».
# Plus d’infos
Posté par gouttegd . En réponse au lien Il y a 6 jours, le premier commentaire fédéré sur une forge logicielle libre (gitea). Évalué à 8.
J’attends ça avec impatience, mais qu’on ne s’emballe pas trop, c’est encore très préliminaire pour l’instant.
On pourra consulter la pull request correspondante pour se faire une idée de ce qui est fait et surtout de ce qui reste encore à faire.
Notamment, rien n’est fait côté interface utilisateur, donc le développeur a dû bidouiller des scripts pour poster son commentaire de test.
Pour l’instant, il faut voir le « premier commentaire fédéré » comme une preuve de concept plus qu’autre chose.
[^] # Re: Je vois pas le rapport!
Posté par gouttegd . En réponse à la dépêche PyPI déploie le système 2FA pour les projets critiques écrits en Python. Évalué à 6.
[Référence nécessaire]
On a des cas de contributeurs à PyPI ou à NPM dont les mots de passe ont été captés par des acteurs malveillants qui les ont ensuite utilisé pour publier du code malveillant au nom de ces contributeurs ?
La dépêche fait référence (sans lien d’ailleurs, ce qui est dommage) à une étude de l’Open Source Security Foundation qui a trouvé « plus de 200 paquets Javascript et Python malveillant ». Il s’agit de ce projet, dont le résumé dit clairement
(L’emphase est de moi.) Les attaques par « confusion de dépendances¹ » et « typosquattage » ne nécessitent aucunement de capturer les identifiants et mots de passe de qui que ce soit. L’attaquant publie les paquets malveillants avec un compte qu’il a créé lui-même et donc qu’il contrôle déjà entièrement. C’est justement un des intérêts de ces attaques que de ne pas nécessiter un quelconque acte de « piraterie » pour être mis en œuvre.
L’authentification à deux, trois, ou douze facteurs n’a strictement aucun effet sur ce genre d’attaques.
L’étude ne mentionne explicitement aucun cas de code malveillant publié avec le compte d’un contributeur légitime qui se serait fait pirater son compte. Je pense que s’ils avaient détecté un tel cas, ç’aurait été suffisamment notable pour mériter une mention.
Donc non, il n’y a pas de rapport entre « tout le monde peut publier sur NPM ou PyPI, du coup il y a des paquets malveillants » et « désormais les projets critiques doivent utiliser l’authentification à deux facteurs ». Le second n’est pas une solution au premier, c’est une solution à un tout autre problème,² et jusqu’à preuve du contraire un problème beaucoup moins répandu que le premier.
¹ En gros, l’attaquant apprend, d’une manière ou une autre, que la cible utilise des paquets PyPI ou NPM privés (hébergés sur un dépôt interne), et du coup publie un paquet avec le même nom sur PyPI ou NPM, ce qui « masque » les paquets hébergés sur le dépôt privé et conduit la victime à télécharcher le paquet fabriqué par l’attaquant plutôt que le paquet hébergé en interne.
² Non pas que ce soit une mauvaise solution (perso j’accueille favorablement toute initiative en faveur de la généralisation de l’authentification à deux facteurs, que j‘utilise moi-même partout où elle est disponible, y compris sur PyPI).
[^] # Re: Compte suspendu
Posté par gouttegd . En réponse au lien Rachat de Twitter par Elon Musk : en fait, non. . Évalué à 5.
Non, c’est un compte @eIonmusk (I majuscule) qui a été suspendu. Le compte
@elonmuskest toujours là.[^] # Re: Une fonction importante supprimée temporairement
Posté par gouttegd . En réponse à la dépêche Inkscape 1.2 vient de sortir avec tout plein de bonnes choses dedans. Évalué à 8.
Pour info, Martin Owens est en quête de cas d’utilisations pour ré-introduire la fonctionnalité sous une forme qui conviendrait au plus grand nombre.
[^] # Re: Atom était encore en vie?
Posté par gouttegd . En réponse au journal Adieu Atom :(. Évalué à 7.
Bah c’est un truc basé sur Electron, hein. C’est pas un éditeur de texte, c’est un navigateur web qui exécute du Javascript pour se comporter comme un éditeur de texte.
Le but de construire une application sur Electron est que ce soit rapide à mettre en place quand on a principalement des développeurs web sous la main (et qu’on ne veut pas recruter des développeurs qui connaissent autre chose), pas que ce soit rapide à l’exécution. D’façon, tout le monde a 32 Go de RAM sur sa machine aujourd’hui, non ?
[^] # Re: Cryptographie fragile
Posté par gouttegd . En réponse à la dépêche QGestpass logiciel de gestion de mots de passe et de sites web. Évalué à 10.
Personne n’a prétendu le contraire.
Pas du tout. On ne compte pas sur le nombre d‘itérations pour « donner aux données une apparence de nombre aléatoire » (ça voudrait dire quoi d’ailleurs ?).
Le nombre d’itérations ne sert pas à augmenter l’entropie, mais à compenser la faible entropie de départ en rendant plus difficile de réaliser une attaque par force brute.
Parce que le problème des mots de passe, c’est justement qu’ils sont vulnérables aux attaques par force brute (contrairement à une suite d’octets aléatoires provenant d’un RNG). Un mot de passe de 8 caractères alphanumériques par exemple, c’est au maximum (26 + 26 + 10)⁸ possibilités. C‘est largement à la portée des machines modernes, qui peuvent calculer plusieurs milliards de condensats SHA2-256 par seconde.
(Et encore, là je ne tiens pas compte de plusieurs facteurs qui rendent les attaques encore plus faisables, comme le fait que les humains sont notooirement très mauvais quand il s’agit de choisir un mot de passe – ce que les craqueurs de mots de passe savent très bien exploiter, notamment en faisant des attaques par dictionnaire plutôt que d’énumérer bêtement toutes les combinaisons de caractères possibles.)
Du coup, puisque le nombre de possibilités à tester est relativement faible (suffisamment faible pour être brute-forceable), on augmente le nombre d’itérations pour que chaque possibilité à tester prenne plus longtemps. Avec 1 000 itérations, une machine capable de calculer un milliard de condensats SHA2-256 par seconde ne peut plus tester qu’un million de possibilités par seconde.
C’est à ça, et uniquement à ça, que sert le nombre d’itérations.
C’est quoi que tu ne comprends pas dans le fait qu’ici l’entrée de la fonction est un mot de passe entré par l’utilisateur ?
Tu ne peux pas ajouter de l’entropie à un mot de passe ! Ta fonction de dérivation doit se débrouiller avec le mot de passe choisi par l’utilisateur.
Lorsque l‘entrée est une suite d’octets (pseudo-)aléatoire (par exemple une graine en provenance directe d‘un RNG), oui. Lorsque l’entrée est un mot de passe, catégoriquement pas.
Le problème n’est pas que SHA2-256 n’est pas « cryptographiquement assez bonne » (elle l’est), le problème est qu’elle est rapide.
L’absence de résistance aux collisions n’a absoluement aucune importance ici.
Fun fact : la principale raison pour laquelle on veut se débarasser complètement de SHA-1 est que les cryptologues ont en assez de devoir expliquer constamment que non, toutes les applications cryptographiques des fonctions de condensation n’ont pas forcément besoin de la propriété de résistance aux collisions.
[^] # Re: Cryptographie fragile
Posté par gouttegd . En réponse à la dépêche QGestpass logiciel de gestion de mots de passe et de sites web. Évalué à 9.
Si, parce qu’ici l’entrée de la KDF est un mot de passe, dont l’entropie est incertaine et toujours considérée comme significativement plus faible qu‘une suite d’octets aléatoires de même longueur.
La fiabilité de la fonction de condensation ne te sauvera pas si l‘attaquant peut brute-forcer ton mot de passe — ce qui ne pose aucune difficulté si la fonction de dérivation ne consiste qu‘en un unique appel à une fonction extrêmement rapide comme SHA2-256.
Ici, on n’a pas besoin d’une Key Derivation Function tout court mais d’une Password-Based Key Derivation Function (PBKDF), qui prend précisément en compte la faible entropie du mot de passe d’entrée.
Du coup ce n’est pas le NIST SP800-108 qu’il faut consulter, mais le NIST SP800-132, qui recommande au minimum 1 000 itérations.
# Cryptographie fragile
Posté par gouttegd . En réponse à la dépêche QGestpass logiciel de gestion de mots de passe et de sites web. Évalué à 10. Dernière modification le 30 mai 2022 à 11:44.
Je n’aime pas écrire ce commentaire, parce que je ne veux pas « descendre » un projet libre partagé « dans l’espoir qu’il sera utile ».
Mais en l’état, je me dois de déconseiller l’utilisation de ce logiciel excepté dans les situations où la menace est quasiment inexistante — autrement dit, si vous ne voulez que stocker vos identifiants sans aucunement chercher à les protéger.
La première phrase de la dépêche dit tout :
Il n’y a bien sûr aucun mal à créer un logiciel dans un but didactique et ce n’est sûrement pas quelque chose qui doit être découragé, bien au contraire.
Mais du côté des utilisateurs potentiels, il faut être conscient de ce que ça implique. En l’occurrence ici, que la protection cryptographique semble reposer sur des bases fragiles.
Un rapide coup d’œil au code montre (au moins, pas tout regardé en détail) deux gros red flags :
C’était acceptable il y a vingt ans, ça… Aujourd’hui l’état de l’art commande d’utiliser des primitives cryptographiques spécialement conçues pour la dérivation de clef. Au minimum PBKDF2, ou mieux encore de nos jours les fonctions de la famille Argon2.
[^] # Re: Signification
Posté par gouttegd . En réponse au lien Microsoft Exchange Online prend en charge SMTP DANE. Évalué à 2.
Observation similaire de mon côté. Les proportions varient d‘un mois à l’autre et il y a clairement des « vagues », mais les comptes Hotmail et GMail représentent toujours une part significative du spam (à la louche je dirais de 25% pendant les périodes « calmes » à plus de 70% pendant les « vagues »).
# Signification
Posté par gouttegd . En réponse au lien Microsoft Exchange Online prend en charge SMTP DANE. Évalué à 10. Dernière modification le 26 mai 2022 à 01:01.
SMTP DANE (DNS-based Authentication of Named Entities) est une méthode permettant d’authentifier un serveur de courrier électronique via des clefs publiques ou des certificats X.509 publiés dans le DNS. Longtemps négligée par les « gros acteurs » (et activement combattue par Google, comme tout ce qui repose sur le DNS plutôt que des solutions à base de web), cette méthode vient d’être adoptée (dans un sens seulement, pour l’instant) par Microsoft pour Exchange Online : désormais, lors de l’envoi d’un e-mail depuis Exchange Online, le serveur vérifiera la présence d’enregistrements TLSA dans le domaine du destinataire, et agira en conséquence (en refusant par exemple de procéder à l’envoi si le serveur du destinataire présente un certificat ne correspondant pas à un des enregistrements TLSA).
L’adoption dans l’autre sens, c’est-à-dire la publication des clefs publiques ou certificats des serveurs Exchange dans le DNS, de sorte qu’un serveur devant envoyer un e-mail à un destinataire utilisant Exchange puisse authentifier les serveurs Exchange préalablement à l’envoi, est annoncée pour fin 2022.
Compte tenu du poids d’Exchange, notamment en milieu professionnel, c’est une très bonne nouvelle pour SMTP DANE et pour le chiffrement généralisé des e-mails en transit.
[^] # Re: Quel less ?
Posté par gouttegd . En réponse au message less demande un suffixe pour lire utf8... et le lit correctement sans!? [en fait, c'est lesspipe.sh]. Évalué à 4.
Note to self : toujours rafraîchir la page avant de poster un message… ><
[^] # Re: Quel less ?
Posté par gouttegd . En réponse au message less demande un suffixe pour lire utf8... et le lit correctement sans!? [en fait, c'est lesspipe.sh]. Évalué à 4.
Vérifie si less utilise un préprocesseur, c’est peut-être ce préprocesseur qui affiche ce message. As-tu une variable
LESSOPENdans ton environnement, et si oui que contient-elle ?[^] # Re: Bref résumé
Posté par gouttegd . En réponse au lien Attaque sur le format d’échange des clefs privées OpenPGP. Évalué à 6.
Aucune idée. Le truc le plus récent que je connaisse date du début du siècle, je doute fort que ça fonctionne encore.
Le truc qui s’en rapproche le plus, aujourd’hui et à ma connaissance, c’est le standard W3C Subresource Integrity, qui permet d’indiquer qu’un script Javascript doit avoir un certain condensat pour être autorisé à s’exécuter :
Mais comme le condensat est fourni par le même site qui demande l’exécution du code Javascript, ça ne protège absolument pas contre le cas de figure où c’est ce site qui est malveillant (si c’était une signature et non un condensat, ça protégerait au moins contre le cas où un pirate prend le contrôle du serveur… à condition que la clef de signature ne soit pas sur le même serveur, sinon le pirate en prend le contrôle aussi et peut ré-émettre des signatures à sa guise).
C’est surtout conçu pour les cas où les fichiers Javascript sont hébergés ailleurs que sur le serveur du site, typiquement sur un CDN. Ça protège contre un CDN malveillant ou contre une attaque entre le CDN et le client, mais pas contre un serveur malveillant.