Il y a un moyen simple de résoudre la crise à court terme et
long terme, c'est d'arreté la politique de capitalisation de la
santé, et redonner les moyens aux hopitaux.
Alors, supposons, est ce qu'avoir 100% de la population française qui travaille dans un hôpital (qui est le maximum théorique à l’échelle de la France pour donner les moyens) empêcherait l'épidémie ?
D'un coté, ça voudrait dire 100% de vaccinés. De l'autre, travailler à l’hôpital n’empêche pas de tomber malade.
Conclusion, donner le maximum théorique de moyen ne va pas résoudre la crise à court terme.
On en arrive assez vite à la question de savoir si la petite fille est en fait une future Hitler.
J'ai une solution élégante pour ça, mais j'ai pas la place dans la marge pour expliquer ça, et j'ai un trolley à prendre (même si la RATP dit qu'il y a du monde sur les voies).
En terme de cinéma, il ne faut pas confondre le ciné états-
unien (et celui qui le copie pour mieux se vendre, à la
manière des films de Besson) avec celui d'autres pays
Bah, y a des films indépendants américain aussi, je pense que qualifié ça d'états uniens, c'est simplifier beaucoup la question, et ça masque les dynamiques.
Je pense que la séparation est plus sur les films qui ont un budget pour être exportés (donc 1) traduit 2) adapté à un public spécifique) et ceux qui n'ont pas.
Hollywood, en temps que nébuleuse qui représente l'industrie du cinéma, a l'expertise à ce niveau vu que c'est en place depuis longtemps. Par comparaison, la Corée du Sud, sauf erreur de ma part, a commencé la modernisation de son industrie du cinéma dans les années 2000 (si je me souviens bien).
Tu fait un truc en langue anglaise, tu touches les USA (330 millions de gens), mais aussi sans doute le royaume uni, l'australie, le canada sans trop de probléme.
À coté de ça, tu fais un film en français, le marché est fondamentalement plus petit. Je parle de marché spécifiquement, car il suffit pas d'avoir des gens qui parlent la langue, il faut aussi les infras qui vont avec, et des gens qui veulent payer pour voir les films. Le Congo a beau avoir le plus de francophones au monde, le taux de pauvreté fait qu'il y a sans doute moins de perspective commerciale.
Donc tu fait un film français, tu as belgique, suisse, france, et sans doute quebec. C'est plus petit que le marché US uniquement.
Du coup, mon hypothèse est que le cinéma hollywoodien, parce qu'il arrive plus facilement à faire des économies d’échelles, a réussi à plus vite s'industrialiser, et à prendre de l'avance.
Demander un budget de 300 millions pour un film que tu va montrer à un marché de 500 millions de personnes, c'est plus facile à justifier que pour un marché de 100 millions. Et du coup, je suppose qu'il y a plus de moyens, et ça part soit dans le fait d'avoir plus d'effets spéciaux, soit d'avoir plus de films (y compris plus de films pourris). Et qui dit plus de films dit sans doute plus de succès au total.
Donc tu te retrouves avec une industrie qui sait ce qui marche grâce à des données depuis des années et qui bosse pour vendre des trucs qui marchent.
Des protestants et la morale judéo-chretienne, on a ça aussi en Europe, mais je ne crois pas (à vérifier) qu'on a eu un équivalent au code Hayes en France, par exemple.
Et par exemple, sur l'inclusion de personnages LGBT dans l'univers Marvel, une des hypothèses n'est pas que le marché US va mal réagir (c'est plus les années 1980), mais plus que la Chine va refuser un visa d'exploitation, et que ça va peser dans la balance commercial.
Les boites auquel je pense c'est RedHat, Microsoft et
Salesforce. C'est pas Amazon ou Apple mais il y a tout de même
un GAFAM dans le lot.
Si par Red Hat, tu veux pointer sur les donations faites en décembre pour curl, plot twist, le virement a été fait par quelqu'un de mon équipe (à savoir Ruth).
Elle a demandé en interne des noms de projets qui peuvent recevoir des dons soit via OpenCollective, soit via une association (en citant SPI et SFC). Ou via Github Donations à condition de passer par Open Collective.
SPI et SFC sont des structures basées aux USA, sauf erreur de ma part. OpenCollective est basé au Delaware, donc je pense que ça va beaucoup plus vite en terme de gestion de risque vu que la loi US s'applique aussi directement sur l'intermédiaire.
Et de plus, le programme en question a été commencé y a un peu plus d'un an avec 3 projets pilotes avant d'étendre à plus, donc quand je dit "il faut un peu de paperasse et de temps", c'est pas juste pour gagner du karma.
Mais oui, une fois que c'est en place, ça va beaucoup plus vite (vu que la demande de noms a été faite le 2 décembre, le virement a été fait le 15, mais Ruth a aussi l'habitude de travailler avec notre direction financière donc je suppose que ça aide pas mal).
Il y a des cas qui sont de vrais problèmes. Je ne sais pas
trop pour Facebook, mais prends un streamer twitch qui a des
modérateurs qui n'ont aucune rémunération pour quelque chose
qui constitue un véritable travail
Oui, clairement. Ensuite, c'est surtout qu'il y a une zone entre "je gagne à peine de quoi payer mes jeux, la caméra et le setup", et "je gagne ma vie et de quoi payer des prestas", et c'est la ou ça devient sans doute tendu quand une personne gagne sa vie et l'autre pas, surtout quand l'investissement en temps semble comparable (vu que si X streame et Y modère pendant ce temps, ça prends plus ou moins le même temps).
Dans le cas de Facebook, Facebook paie des modérateurs (ou plutot, sous traite ça au portugal) et investit dans des IAs pour réduire les couts, mais aussi éviter d'infliger à des humains de faire la modération.
Mais se pose la question de la modération humaine d'un groupe dédié à une structure, comme serait une communauté de fans, par exemple.
Moi, je note surtout que linuxfr n'est pas le top 10 d'un coté ou de l'autre.
C'est assez louche, je pense qu'il y a une censure étatique vis à vis de la moulosphére, et qu'on essaye de museler l'opposition philosophique au modèle capitalo-proprio poussé par Bill Gates et France Télécom.
Historiquement, le fascisme (qu'on va en général ranger dans "extrême droite") est souvent lié à une forme de mensonge.
Par exemple, le NSDAP (le partie nazi) s'est présenté à la base comme anti bourgeois (c'est dans le nom en allemand, le A pour Arbeiterpartei), puis à changé du tout au tout vers l'anti-marxisme pour obtenir le support de l'industrie.
Ce fut le même topo en Grèce de ce que je sais, et j'imagine en Italie (même si je connais un peu moins tout ça). C'est aussi ce qu'on retrouve dans le texte d'Umberto Eco sur le fascisme eternel:
Thus, by a continuous shifting of rhetorical focus, the enemies are at the same time too strong and too weak.
On retrouve aussi le mensonge dans l'idée que c'était mieux avant, eg l'appel à la tradition (mensonge sur le fait que c'était en général pas mieux avant sauf sans doute pour des élites spécifiques). On le retrouve aussi dans l'idée d'un complot international (exemple, les Protocoles des Sages de Sion et son usage dans Mein Kampf).
Donc l'usage du mensonge est fondateur dans certaines théories d’extrême droite.
Malgré la présence importante de productions russes dans le top 10 (sputnik, RT), ou de sites qui "relaie de la propagande russe" (Planetes360, TVlibertes), je pense qu'on peut être fier de voir qu'on a quand même des productions de chez nous comme FranceSoir ou pour un coté un peu plus terroir, Breizh info.
Ça fait chaud au coeur de voir que nos productions françaises n'ont pas à rougir face à l'industrie de St Peterbood qui inonde nos écrans.
(c'est du sarcasme, pour le cas ou c'est pas clair)
Tu donne l'impression que les entreprises ne peuvent pas
payer et que c'est une paperasse incommensurable digne des
travaux d'Hercule, ce n'est vraiment pas le ressenti que
j'ai de la part des personnes qui font ces démarches.
Il est possible en effet que la multinational qui m'emploie soit un cas extrême. Je vois le temps qu'on a mis pour avoir 1 fournisseur dans le système, c'était assez décourageant, donc j'imagine pas vraiment faire ça sur 20 à 30 logiciels.
Ensuite, encore une fois, pour une boite plus petite, je ne doute pas que c'est beaucoup plus simple. Une PME va juste faire le virement et basta.
Mais en général, c'est rarement les PME qu'on accuse de profiter du logiciel libre sans rien donner en retour.
Boh ça tu as pleins de cas louche. Si je contribue à un
logiciel libre disons gitlab, est-ce que ça n'est pas du
travail déguisé pour une entreprise qui va profiter de mon
travail comme produit d'appel ? Je suis curieux de savoir
comment la DGCCRF voit ce genre de choses.
Je suppose que le point important, c'est la relation de subordination. À priori, je pense qu'il n'y a pas de relation de subordination entre un projet lambda (gitlab) et un codeur lambda (barmic).
Mais tu as raison de pointer ça, et je pense que c'est une question qui s'inscrit dans la réflexion autour des réseaux sociaux et du travail de création fait par les utilisateurs.
Ton exemple me parait plus équitable que les histoires autour de Facebook, car Gitlab va aussi contribuer au pot commun, même si, comme tu le pointes, c'est un produit d'appel.
Mais je n'ai pas dit "une interdiction", j'ai parlé de "c'est pas si simple". C'est rien d'insurmontable, vu qu'on arrive à faire le sponsoring.
Et comme tu le souligne, la boite qui paye doit vérifier, mais vérifier, c'est de la paperasse, et c'est un peu intrusif hélas.
Genre, si demain on dit "on veut te filer des thunes, mais on a besoin de ta carte d'identité pour vérifier ta nationalité", ça va faire grincer des dents à juste titre.
L'exemple du FOSDEM est aussi un bon exemple parce que le FOSDEM est une assoce, c'est établi et le sponsoring est tout les ans. Donc tu fais la paperasse une fois, et ça parait pas louche, et ça va.
Payer des devs une fois, c'est autre chose.
Et je ne parle pas de la question du travail déguisé, parce qu'il y a aussi ce coté intéressant (à savoir que si une boite file de l'argent à X pour faire du travail sur un logiciel Y qui est vendu/utilisé, je comprends que les impôts regardent ça d'un œil bizarre car c'est comme une presta sans payer d’impôts, et les impôts, ils aiment pas ça)
Les États Unis ont un certain nombre de loi fédéral vis à vis de la corruption, notamment le Foreign Corruption Practice Act (loi sur la corruption à l'étranger).
Moi, j'ai la nationalité française, je bosse à Paris, avec un contrat français avec une boite française en temps qu'admin sys. Et pourtant en pratique, ça impacte ma vie professionnelle de plusieurs façons, car mon employeur est filiale de filiale d'une boite aux USA, elle même filiale d'une boite plus grande, aussi aux USA.
Primo, tout les ans, toute la boite a une formation obligatoire sur le sujet du FCPA. C'est une formation sur le web, avec des vidéos, des questions, et ça tombe en hiver. On a aussi une sensibilisation vis à vis du RGPD et de la sécurité.
Pendant des années, ça a été illustré par la même histoire sur la construction d'un stade dans un pays imaginaire, ou quelqu'un sous pression de son sous traitant paye un pot de vin pour finir la construction à temps d'un stade (eg, contourner la demande de permis qui va prendre 4 mois), mais … le stade s'effondre à cause de ça 2 slides plus tard, et c'est mal(tm).
La formation a fini par être refondu (donc avec d'autres histoires) au bout d'un certain temps mais ça avait fini par devenir un meme en interne. Je suis assez fier de faire un score parfait chaque année depuis 5 ans en français ou en anglais, mon objectif est de réussir à faire la formation dans une 3eme langue, car on s'occupe comme on peut.
Secundo, et c'est la ou ça devient intéressant, c'est que les USA sont assez rigide sur la question de la corruption, dans le sens ou ils estiment que si il y a un acte de corruption dans ta chaîne de responsabilité même dans un autre pays, tu es responsable.
Si moi, je paye un pot de vin pour passer la douane plus vite pour aller à Yerevan en Arménie dans le cadre du boulot (histoire arrivé à un collègue dans un autre cadre), alors mon employeur est responsable aux yeux de la justice américaine, et quelqu'un peut aller en taule ou avoir une amende. Je ne sais pas si c'est le cas aussi en France, mais en général, ça surprends pas mal de savoir que les USA considèrent que leur loi s'applique en dehors de leur territoire et sur les non ressortissants.
Autant dire que le consensus sur les 6 niveaux de chef au dessus de moi, tous aux USA, est qu'il ne faut pas tenter le diable, d’où les formations, et des vérifications sur les notes de frais, etc, etc.
Je suis admin sys, donc le risque de filer des pots de vins à un douanier est assez mince. Mais la corruption, vis à vis de la loi des USA, c'est défini de façon assez large, dans le sens ou si ça implique de l'argent et quelqu'un lié à un état, c'est louche.
Par exemple, si je fait un tirage au sort pour gagner un smartphone sur un stand du FOSDEM, et paf, c'est une fonctionnaire espagnole qui gagne, ça peut être vu comme de la corruption. Si je paye un repas avec la carte bleue de la boite à un prof norvégien toujours lors du FOSDEM, ça peut être vu comme de la corruption.
Et surtout, je file du cash ou je fait un virement à un étudiant en doctorat (cad, quelqu'un en France payé par l'état), ça peut être vu comme de la corruption.
Et la ou ça devient encore plus drôle, c'est que c'était déjà assez lourd, mais on a aussi le concept (dont j'ai oublié le nom exact) d'entreprise quasi gouvernemental.
Exemple, EDF. EDF n'est pas le gouvernement français, mais le gouvernement français a la majorité des parts, donc ça compte comme si c'était le gouvernement. Et EDF a des sous traitants, donc techniquement, les sous traitants peuvent compte comme EDF, donc comme des fonctionnaires vis à vis de la loi US anti corruption à l'étranger.
Donc prenons un example. Supposons que Roberta Codeusedelogquatreji, qui travaille bosse pour EDF dans une ESN et qui bosse sur log4j sur son temps libre. Mon employeur ne devrait pas lui faire de virement direct pour soutenir log4j, parce qu'elle bosse pour EDF, et donc on a des vérifications à faire avant pour pas avoir d'emmerde avec la justice des USA.
Je ne dit pas que c'est pas faisable, mais c'est relou. Par exemple, on a maintenant un tableau listant les montants et les circonstances des exceptions (par origine de la personne qui paye et de la personne qui recoit, et du statut de la personne qui recoit et de ou ça se passe et comment ça se passe), et "filer du cash" n'est pas dessus (payer des repas, des goodies, oui), donc il faut demander. Et connaissant la boite, je suppose que ça va aussi vite que d'avoir un laisser passer A-38.
Ça c'est pour le FCPA.
Ensuite vient la question de l'OFAC. C'est l'Office of Foreign Assets Controls, le bureau du contrôle des biens étrangers.
C'est un département du ministère des finances des USA, en charge de faire appliquer des sanctions économiques (parmi tant d'autres). En gros, les ressortissants US n'ont pas le droit d'interagir économiquement avec les gens sur la liste publié par l'OFAC. La liste est sur le site web, un fichier texte de 9 megaoctets avec 6300 entités (personne, entreprise, etc).
Comme la politique étrangère du pays n'est pas caractérisé par sa subtilité, il y a directement des pays sur la liste comme l'Iran, la Corée du nord, la Syrie, etc. Ça a donné des choses comme ici, ici, ici au cours des années.
La liste des sanctions est assez complexe, et change régulièrement. Par exemple, c'est aussi l'OFAC qui fait qu'il est interdit d'importer du matériel produit par de la main d'oeuvre Ouïghour (donc je sens que mon prochain serveur va prendre un peu plus de temps à commander à cause de ça.
Donc techniquement, une boite US qui file des thunes à un dev de log4j qui est un citoyen d'Iran (même vivant à l'étranger) serait dans la merde, car c'est interdit. Et le souci de l'OFAC, c'est que ça dépend directement du président (donc non élu), et qu'ils sont un chouia rigide et pas exactement sympa. De ce que j'ai compris, ça ne va pas changer de si tôt, et personne n'a vraiment envie d'attirer l'attention des impôts en demandant des exceptions.
Ensuite, je ne connais pas la loi française. Je ne doute pas que ça soit plus souple, mais je suppose que faire cracher l'argent à une banque, ç'est aussi non trivial, en partie parce que même une banque française va vouloir respecter la loi US pour ne pas se fermer ce marché ou se faire bloquer l'accès à SWIFT. C'est aussi exactement pour ça que l'Europe a mis en place des choses comme INSTEX, ou des lois visant à protéger les entreprises qui ont une relation commercial avec l'Iran.
Donc voila, c'est la version longue de "on peut pas filer de l'argent n'importe comment sinon des stades risquent de s'effondrer". Je ne doute pas que dans une petite boite, ça se passe autrement, et peut être que c'est juste mon employeur qui est particulièrement prudent. Mais je pense qu'à partir d'une certaine taille, tout le monde devient prudent.
Tu montes une boite/association qui envoie la facture en son
nom.
Alors je ne doute pas qu'il y a des tas de moyens de contourner le FCPA ou les sanctions de l'OFAC, mais je garde mes compétences spéciales pour les cas spéciaux.
Et si j'en crois les trainings annuels, si je respecte pas la loi à la lettre, y a un stade qui va s'effondrer dans un pays pauvre non spécifié 6 mois après, ou un truc comme ça.
Pour moi, ce qui manque, c'est la possibilité de limiter
l'accès réseau et l'accès au FS de façon simple, sans passer
par du selinux
Alors, ce que tu veux, c'est pas simple. Je veux bien reconnaître que la syntaxe de selinux est pourri, mais même avec une syntaxe moins pourri, ça serait lourd, car la lourdeur ne vient pas que de la syntaxe, mais du fait qu'il faut lister tout les accès, et ça prends du temps, c'est pour ça que les gens ont tendances à ne pas le faire.
Et c'est pas un souci technique, car des méthodes hors SELinux, y en a.
Tu veux filtrer l’accès réseau, tu as iptables (et nftables) en sortie, avec par exemple le match "owner".
Tu veux filter l'http, tu peux mettre un proxy squid en sortie, et mettre des ACL sur la destination.
Tu veux restraindre le FS par application, tu as systemd, avec ProtectHome et tout ce qui va avec (InaccessiblePaths, ReadOnlyPaths, etc, cf systemd.exec
Ou, si tu as de l'argent pour refaire le SI, Openshift (et donc Kubernetes avec les bons réglages) lance les applications sans accès root dans des namespaces séparés, avec un fs en read only (sauf répertoire spécifique explicitement indiqué). Tu peux aussi filtrer en sortie avec les NetworkPolicies.
Et du coup, chaque application qui tourne dans un conteneur doit indiquer les volumes en lecture/écriture, les ports en entrée, et le stockage est normalement séparé par application, donc un peu comme pour Android.
Mais voila, comme android, ça implique de balancer tout le travail déjà fait, ou de bâtir des choses par dessus l'existant. Et il faut gérer la machinerie aussi, bien sur.
J’ai donc du mal à croire à priori que ce pauvre chauffeur ait
trouvé le bug critique qui lance la voiture full patate sans
aucun input.
Alors, je suis d'accord avec l'idée mais mon optimisme ne me permet pas d'envisager un code sans bug à la con.
Et une autre hypothèse aurait pu être un bug matériel qui a aboutit à une erreur sans faire crasher tout le soft (car oui, ça peut aussi arriver).
Ou, Tesla ne déploie pas ses firmwares partout en même temps, et c'était une pre release (style dark deploy à la google) avec un bug à la con, mais la boite ne veut pas le dire.
Je vais pas lister tout la page wikipedia, mais je me souviens de l'histoire de mentir sur les accidents dans ses usines en 2018, donc je sais pas trop si on peut encore donner le bénéfice du doute à la boite.
Je pense surtout que la question est de savoir qui est responsable.
Autant pour un taxi autonome (exemple, waymo), ç'est la même chose qu'avec un taxi normal (eg, pas le passager), autant c'est plus compliqué quand c'est une voiture privé, et que tu es sans doute moins censé avoir une personne assigné à ta voiture (car c'est aussi l'idée, c'est d'avoir un chauffeur sans avoir à le payer au prix d'un chauffeur maintenant).
on demandait beaucoup plus aux applications (logs, métriques,
tableaux de bord) avant
Je pense que les bonnes pratiques maintenant, c'est aussi d'avoir les métriques dispos pour usage via prometheus via HTTP, ou d'être kubernetes-compatible (pour le "readyness probe" et "liveness probe", via HTTP aussi).
Ensuite, c'est peut être après demain dans certains SI, voir la semaine prochaine, quand le passage à la virtualisation sera fini (juste après la migration à RHEL 6)
Mais je sais qu'il y a des gens qui stockent plus que simplement des comptes dans un annuaire LDAP. Avec LDAP, tu as quand même:
- une réplication
- un système d'ACL sur qui peut écrire quoi
- des API pour la majorité des langages
Supposons que tu as une tonne d'application en java (genre 200/300). Pour savoir qui est responsable de ça, tu as besoin d'une liste, et si la liste pouvait être aussi utilisable pour les accès aux serveurs, ça serait pas mal chouette.
Donc tu te dit "on peut mettre chaque appli dans l'annuaire", après tout, il est la, ça te coûte virtuellement rien de plus vu que l'annuaire est déjà "payé" (eg, y a des backups, les ports sont ouverts, y a des ACLs, y a la redondance et la réplication). Et surtout, son uptime, c'est le souci de quelqu'un d'autre, et ça sera son souci que tu l'utilises ou pas.
Mais une fois que tu as ça dans l'annuaire, alors c'est tenant de t'en servir pour savoir par exemple qui recoit les mails quand ça crashe. Parce que oui, log4j permet de faire ça, et donc de faire 1 fichier de config unifié sur toutes les applis qui dit "chaque application qui envoie un message de niveau X va envoyer ça par mail aux gens qui sont listés dans l'annuaire sous le groupe qui correspond au nom de l'application", c'est assez propre, vu que l'info est a un seul endroit.
Autre avantage, tu peux laisser chaque groupe modifier ses préférences de journalisation via LDAP sans donner directement un accès aux serveurs en prod pour toucher la config. Et en fait, sans leur demander d'apprendre à faire du XML, de l'ansible ou autre chose. Quand tu as des gens qui vont et qui viennent, voir qui vont d'un projet à un autre, c'est une solution.
Est ce que ça arrive souvent, je sais pas, je bosse pas dans une banque, et j'ai pas 200 applis java à gerer.
Est ce qu'il y a des tas de façons de faire sans ça, clairement. Des alias mails, une base de données spécifiquement, ou juste embaucher des gens plus cher qui savent faire du XML et du ssh (sans doute non compatible avec "on va réduire le budget" ceci dit).
Et de toute façon, la question n'est pas "pourquoi LDAP ?" en particulier, mais "pourquoi du dynamique ?".
log4j, c'est des logs, mais fondamentalement, les logs, c'est du routage de flux texte. Et si on voit la logique d'avoir la possibilité pour postfix de faire des lookups LDAP, alors je peux imaginer des cas ou ça peut servir aussi pour log4j (cf mes exemples inventés).
Si le journal des événements windows est troué, le correctif
pourra arriver avec quelques années de retard, mais ce sera
assez simple de le déployer , puisque seul windows l'utilise
Je pense que ça va rien changer au fait que certaines infras (à tort ou à raison) sont longues à être mise à jour.
La différence entre log4j et windows, c'est qu'en tant qu'admin, je suis responsable de windows, mais pas forcément de log4j.
Un meilleur exemple serait un logiciel proprio qui n'est pas directement fourni à l'admin. Je sais que l'exemple que je vais donner est pourri, mais je connais pas assez de logiciel proprios.
Prenons qnx. C'est un logiciel qui a du succès, mais c'est en général pas moi en tant qu'admin qui va le mettre à jour, mais le fabricant qui me file un firmware. Si on retire les soucis de mise à jour de firmware (aka, c'est chiant de base), on va être dans le même genre de problématique, à savoir qu'il y a 3 acteurs:
- le fournisseur du composant
- les fournisseurs du logiciel qui utilisent le composant
- l'utilisateur des logiciels.
Ça va être plus long qu'un truc avec 2 acteurs car il y a beaucoup plus de monde.
Personnellement, je suis plutôt surpris qu'il y ait si peu
d'attaques de ce genre. Pour l'instant, la majorité de celles
qu'on connaît ont touché l'écosystème Javascript.
Y a beaucoup sur npm, mais l’écosystème python est aussi impacté pas mal via du typosquatting régulier, donc je dirais pas vraiment "la majorité".
À titre semi personnel (semi personnel parce que je garde ça pour le boulot, mais surtout pour ressortir des exemples quand je doit convaincre le reste du monde), j'ai une liste sur l'intranet du boulot avec toute les compromission touchant à du code source sur les infra de logiciel libres et dans mon souvenir, c'était de l'ordre de 1 par mois en 2019/2018, tout projet et type de compromission confondu.
Je devrais la publier de l'autre coté du firewall un jour je suppose.
Je pense pas que ça soit toujours aussi simple que le résumé de ton prof.
Par exemple, faire changer le mot de passe tout les 6 mois, ç'est clairement moins de confort. Par contre, le gain en sécurité est assez marginal (voir négatif) si j'en croit divers discussions sur le sujet.
Et de surcroit, ça ne dit ni sécurité contre quel type d'attaque, ni confort pour qui ?
Ton exemple de la banque est une bonne illustration, car le manque de confort est ressenti par l'utilisateur, mais le bénéfice de sécurité est surtout pour le bénéfice de la banque (vu que l'utilisateur va être couvert plus ou moins via le jeu des assurances et de la loi).
Dans ce cas, posons la question, est ce qu'il y avait besoin de log4j, si on suppose qu'on peut toujours faire sans certaines fonctions ?
Après tout, pourquoi ne pas rester à Println ou la lib par défaut de java ?
Quelqu'un a eu besoin de chaque bout de fonctionnalité ajouté à un moment. Quelqu'un l'a codé. Je suppose que c'est grosso modo tout ce qu'il faut.
La maintenance, c'est important, mais je sais aussi que dire "non", c'est en général assez peu populaire comme position, comme j'ai pu le voir sur le projet Ansible quand des modules ont été refusés, comme on a pu le voir lorsque que Debian a décidé de passer à systemd, ou les discussions sur les thèmes de GNOME.
Sans aller loin dans le passé, il suffit de voir il y a une semaine sur Linuxfr la discussion sur le manifest v3 et le fait de retirer des fonctionnalités en cadrant un peu mieux ce qui est faisable ou pas.
Dans le cas de log4j, le souci n'est pas forcément de rajouter le lookup jdni, car de ce que j'ai compris, c'était prévu pour être fait via la configuration sous le contrôle d'un admin. Avoir la configuration des logs centralisés dans LDAP via une syntaxe standard de Java, c'etait pas non plus déconnant.
La question d'activer jdni par défaut ou pas, c'est au niveau de la JVM, et pareil, je suppose que les devs de JVM ont du se dire "si quelqu'un utilise la fonction dans le code, alors c'est implicitement qu'il a besoin de l'utiliser".
On peut se poser la question de la gestion récursive des variables, mais je sais que j'ai déjà eu besoin de ça avec ansible, donc je suis assez sur que d'autres auraient pu en avoir besoin dans d'autres contextes, et qu'un dev aurait pu le rajouter en tout bonne foi.
Et pour l'usage de la réflexivité, je suppose que c'est un pattern important pour java (ou du moins, ça avait l'air important quand j'ai appris java).
Ensuite, il faut aussi rappeler que les lookups JDNI sont maintenant désactivés par défaut sur les JVM d'il y a moins de 3 ans (si je me souviens bien) et surtout qu'il existe un concept de sandbox dans la JVM depuis grosso modo toujours. Sandbox qui n'est semble t'il pas utilisé par la majorité des programmes, car ç'est long à coder. Et qui n'est pas activé par défaut, car ça n'aboutirais que à forcer les gens à retirer dés qu'un truc ne marche pas (cf les tutos partout qui commence par "il faut retirer selinux")
Alors, moins de fonctionnalité, sans doute que oui, mais il faut bien voir que dire "non", c'est mal vu, et que dire non ne retire pas le besoin, et qu'à un moment, tu va commencer à perdre des utilisateurs, puis des contributeurs, et le souci n'a fait que bouger ailleurs.
OpenBSD a moins de fonctions qu'une distro Linux. Mais curieusement, les distros Linux sont massivement plus utilisés.
Mais il est clair que si log4j pourrait recevoir des
contributions financières, ce serait cool.
Log4j fait parti de la fondation Apache, donc la structure pour recevoir de l'argent est de facto la (cf son ancien président qui m'a pointé ça quand on a eu la même discussion).
Concernant le CI , oui un mvn audit serait bien, encore
faudrait il que eles serveurs maven suivent (il n'y a pas
uniquement maven central )
Et il faut avoir l'infrastucture et les procédures pour gérer des failles. C'est amusant de comparer ça avec npm (qui a la fonction, mais aussi des gens pour s'en occuper, d'autant plus depuis le rachat par github et par microsoft), ou avec pypi (qui n'a personne pour faire le taf, ou du moins, qui n'avait personne à temps plein sur la maintenance du logiciel avant, et sans doute des volontaires sur le reste).
Des modèles de financement existent (que ça soit des choses comme Anaconda, les distros commerciales, ou sans doute d'autres), mais j'ai pas le sentiment que "il faut se retreindre à ne prendre que des biblis supportées ou on paye" soit la grande tendance du moment.
Ouais, enfin, dans une grande boite, sortir l'argent, c'est pas si simple.
Par exemple, tu fais du libre et tu envoies une facture, mais tu es étudiant en doctorat à Paris ? Mon employeur ne peut sans doute pas te payer, car un doctorant est payé par l'état, et les lois anticorruptions américaines s'appliquent (vis à vis de filer de l'argent aux agents gouvernementaux).
Tu bosse dans l'informatique, et tu envoies des factures à coté de ton taf, je suppose que la clause de non concurrence s'applique, donc sans doute niet aussi.
Et les taxes divers et variés, surtout d'un pays à l'autre, c'est compliqué.
On peut regarder ce qui est arrivé avec Heartbleed et OpenSSL.
OpenBSD a fait un fork de son coté avec LibreSSL, tout comme Google. Amazon a proposé s2n.
C'est aussi une des raisons de la création du Project Zero de Google, d'aprés WP.
À coté, Go a eu sa propre lib, Rust a RusTLS, et les autres sans doute pareil, pour éviter de se servir d'OpenSSL.
La Linux Fundation a crée une initiative pour financer le libre, c'est un peu sa raison d'être.
Grace à ça, OpenSSL a récolté assez d'argent pour financer un dev à temps pleins, le code a été nettoyé, et on a pas eu autant de frayeur depuis. Et on a tous découvert que la crypto, c'est important.
À coté de ça, je n'ai pas entendu parler de la moindre exploitation publique du bug qui a eu un impact. Je ne doute pas que des groupes bien financés (états) ont pu en tirer quelque chose, mais 7 ans après, toujours rien, ce qui personnellement me conforte dans mon opinion vis à vis des soucis de cryptos.
On peut aussi regarder ce qui est arrivé avec Shellshock et bash, cad, rien de notable. Personne n'a lancé de nouveau shell, d'initiative pour financer bash.
Et que je sache, les impacts sur le monde ont été assez mineur aussi. Il y a eu quelque DDos, sans doute divers companies de pentest qui ont pu sortir des rapports à leur client, mais c'est tout. Je ne doute pas que plus de cibles ont été attaqués, mais pas grand monde a changé de posture.
Donc qu'est ce qui va arriver ?
Primo, plus de gens vont regarder log4j, et les logiciels adjacents. Le bundling de code est une leçon qu'on redécouvre régulièrement (CVE-2002-0059, qui a poussé les distros a faire du dynamique, si je me souviens bien), je suppose que ça va continuer.
Le monde du libre ne va pas trop changer. Il y a déjà des outils pour vérifier les dépendances, donc peut être plus de monde vont commencer à regarder ça. Les gens qui n'aiment pas java vont continuer à ne pas aimer java, les gens qui ne pigent rien à la complexité logiciel vont continuer à poster des commentaires, les mainteneurs vont utiliser ça pour dire qu'il faut changer le fonctionnement du financement du libre sans que ça change.
Le monde du dev interne proprio va sans doute continuer à se diviser entre "les gens qui s'en préoccupent et qui filent des moyens", et "le reste". Avec un peu de chance, les gens sans budget vont réussir à avoir une excuse pour avoir du budget.
Le monde des boites commerciales ne va pas changer beaucoup plus ses pratiques, à part que les équipes sécurité vont avoir un slide de plus pour tenter de tirer du pognon. Je ne doute pas que sur les 5 prochaines années, les choses vont aller mieux, mais c'est sans doute un changement commencé y a longtemps.
Et ce qui ne va pas arriver:
On ne va pas beaucoup plus regarder ce qui est embarqué. Ç'était un souci avant, on ne le faisait pas car c'était trop cher, aucune des raisons pour changer ça n'a changé, donc ça va sans doute bouger un peu mais pas d'un coup.
On ne va pas forcément plus verrouiller les programmes. Elastic Search n’était pas vulnérable à l’exécution de code à distance grace à l'usage d'un ContextManager. Mais de ce que j'ai compris, c'est chiant de rajouter ça dans le code, tout comme c'est chiant de faire des politiques SELinux, et chiant de faire un réseau segmenté avec des parefeux, des proxys, etc. Spoiler, ça va toujours être aussi chiant, donc on va pas plus le faire d'un coup.
On ne va pas arrêter de coder en java. Il y a toujours des tonnes de devs, donc c'est toujours aussi facile d'embaucher, donc le code va continuer à être écrit et maintenu.
On ne va pas arrêter d'embarquer tout. Pareil, ça va toujours être plus facile, ça résout des soucis (ou du moins, ça échange des soucis). Tout au plus, on va voir maven obtenir la même fonction que npm (eg, npm audit), et qui va être ignoré, sauf par les gens avec assez de CI/CD.
[^] # Re: Que les non-vaccinés restent chez eux s'ils tombent malades
Posté par Misc (site web personnel) . En réponse au lien Tenir bon. Évalué à 2.
Alors, supposons, est ce qu'avoir 100% de la population française qui travaille dans un hôpital (qui est le maximum théorique à l’échelle de la France pour donner les moyens) empêcherait l'épidémie ?
D'un coté, ça voudrait dire 100% de vaccinés. De l'autre, travailler à l’hôpital n’empêche pas de tomber malade.
Conclusion, donner le maximum théorique de moyen ne va pas résoudre la crise à court terme.
[^] # Re: Défi narratif
Posté par Misc (site web personnel) . En réponse au lien 2021 : Les 3 lois de la robotique ne sont pas respectées ;-(. Évalué à 2.
On en arrive assez vite à la question de savoir si la petite fille est en fait une future Hitler.
J'ai une solution élégante pour ça, mais j'ai pas la place dans la marge pour expliquer ça, et j'ai un trolley à prendre (même si la RATP dit qu'il y a du monde sur les voies).
[^] # Re: Mens sana…
Posté par Misc (site web personnel) . En réponse au journal J'ai regardé la série Fondation.. Évalué à 5.
Bah, y a des films indépendants américain aussi, je pense que qualifié ça d'états uniens, c'est simplifier beaucoup la question, et ça masque les dynamiques.
Je pense que la séparation est plus sur les films qui ont un budget pour être exportés (donc 1) traduit 2) adapté à un public spécifique) et ceux qui n'ont pas.
Hollywood, en temps que nébuleuse qui représente l'industrie du cinéma, a l'expertise à ce niveau vu que c'est en place depuis longtemps. Par comparaison, la Corée du Sud, sauf erreur de ma part, a commencé la modernisation de son industrie du cinéma dans les années 2000 (si je me souviens bien).
Tu fait un truc en langue anglaise, tu touches les USA (330 millions de gens), mais aussi sans doute le royaume uni, l'australie, le canada sans trop de probléme.
À coté de ça, tu fais un film en français, le marché est fondamentalement plus petit. Je parle de marché spécifiquement, car il suffit pas d'avoir des gens qui parlent la langue, il faut aussi les infras qui vont avec, et des gens qui veulent payer pour voir les films. Le Congo a beau avoir le plus de francophones au monde, le taux de pauvreté fait qu'il y a sans doute moins de perspective commerciale.
Donc tu fait un film français, tu as belgique, suisse, france, et sans doute quebec. C'est plus petit que le marché US uniquement.
Du coup, mon hypothèse est que le cinéma hollywoodien, parce qu'il arrive plus facilement à faire des économies d’échelles, a réussi à plus vite s'industrialiser, et à prendre de l'avance.
Demander un budget de 300 millions pour un film que tu va montrer à un marché de 500 millions de personnes, c'est plus facile à justifier que pour un marché de 100 millions. Et du coup, je suppose qu'il y a plus de moyens, et ça part soit dans le fait d'avoir plus d'effets spéciaux, soit d'avoir plus de films (y compris plus de films pourris). Et qui dit plus de films dit sans doute plus de succès au total.
Donc tu te retrouves avec une industrie qui sait ce qui marche grâce à des données depuis des années et qui bosse pour vendre des trucs qui marchent.
Des protestants et la morale judéo-chretienne, on a ça aussi en Europe, mais je ne crois pas (à vérifier) qu'on a eu un équivalent au code Hayes en France, par exemple.
Et par exemple, sur l'inclusion de personnages LGBT dans l'univers Marvel, une des hypothèses n'est pas que le marché US va mal réagir (c'est plus les années 1980), mais plus que la Chine va refuser un visa d'exploitation, et que ça va peser dans la balance commercial.
[^] # Re: Comme openssl
Posté par Misc (site web personnel) . En réponse au journal log4shell : Et après ?. Évalué à 3.
Si par Red Hat, tu veux pointer sur les donations faites en décembre pour curl, plot twist, le virement a été fait par quelqu'un de mon équipe (à savoir Ruth).
Elle a demandé en interne des noms de projets qui peuvent recevoir des dons soit via OpenCollective, soit via une association (en citant SPI et SFC). Ou via Github Donations à condition de passer par Open Collective.
SPI et SFC sont des structures basées aux USA, sauf erreur de ma part. OpenCollective est basé au Delaware, donc je pense que ça va beaucoup plus vite en terme de gestion de risque vu que la loi US s'applique aussi directement sur l'intermédiaire.
Et de plus, le programme en question a été commencé y a un peu plus d'un an avec 3 projets pilotes avant d'étendre à plus, donc quand je dit "il faut un peu de paperasse et de temps", c'est pas juste pour gagner du karma.
Mais oui, une fois que c'est en place, ça va beaucoup plus vite (vu que la demande de noms a été faite le 2 décembre, le virement a été fait le 15, mais Ruth a aussi l'habitude de travailler avec notre direction financière donc je suppose que ça aide pas mal).
Oui, clairement. Ensuite, c'est surtout qu'il y a une zone entre "je gagne à peine de quoi payer mes jeux, la caméra et le setup", et "je gagne ma vie et de quoi payer des prestas", et c'est la ou ça devient sans doute tendu quand une personne gagne sa vie et l'autre pas, surtout quand l'investissement en temps semble comparable (vu que si X streame et Y modère pendant ce temps, ça prends plus ou moins le même temps).
Dans le cas de Facebook, Facebook paie des modérateurs (ou plutot, sous traite ça au portugal) et investit dans des IAs pour réduire les couts, mais aussi éviter d'infliger à des humains de faire la modération.
Mais se pose la question de la modération humaine d'un groupe dédié à une structure, comme serait une communauté de fans, par exemple.
[^] # Re: Des productions françaises !
Posté par Misc (site web personnel) . En réponse au lien Le top 10 des mésinformateurs francophones . Évalué à 10.
Moi, je note surtout que linuxfr n'est pas le top 10 d'un coté ou de l'autre.
C'est assez louche, je pense qu'il y a une censure étatique vis à vis de la moulosphére, et qu'on essaye de museler l'opposition philosophique au modèle capitalo-proprio poussé par Bill Gates et France Télécom.
Nous sachons
[^] # Re: Surprise !
Posté par Misc (site web personnel) . En réponse au lien Le top 10 des mésinformateurs francophones . Évalué à 7.
Oui, c'est pas super étonnant.
Historiquement, le fascisme (qu'on va en général ranger dans "extrême droite") est souvent lié à une forme de mensonge.
Par exemple, le NSDAP (le partie nazi) s'est présenté à la base comme anti bourgeois (c'est dans le nom en allemand, le A pour Arbeiterpartei), puis à changé du tout au tout vers l'anti-marxisme pour obtenir le support de l'industrie.
Ce fut le même topo en Grèce de ce que je sais, et j'imagine en Italie (même si je connais un peu moins tout ça). C'est aussi ce qu'on retrouve dans le texte d'Umberto Eco sur le fascisme eternel:
On retrouve aussi le mensonge dans l'idée que c'était mieux avant, eg l'appel à la tradition (mensonge sur le fait que c'était en général pas mieux avant sauf sans doute pour des élites spécifiques). On le retrouve aussi dans l'idée d'un complot international (exemple, les Protocoles des Sages de Sion et son usage dans Mein Kampf).
Donc l'usage du mensonge est fondateur dans certaines théories d’extrême droite.
# Des productions françaises !
Posté par Misc (site web personnel) . En réponse au lien Le top 10 des mésinformateurs francophones . Évalué à 5.
Malgré la présence importante de productions russes dans le top 10 (sputnik, RT), ou de sites qui "relaie de la propagande russe" (Planetes360, TVlibertes), je pense qu'on peut être fier de voir qu'on a quand même des productions de chez nous comme FranceSoir ou pour un coté un peu plus terroir, Breizh info.
Ça fait chaud au coeur de voir que nos productions françaises n'ont pas à rougir face à l'industrie de St Peterbood qui inonde nos écrans.
(c'est du sarcasme, pour le cas ou c'est pas clair)
[^] # Re: Comme openssl
Posté par Misc (site web personnel) . En réponse au journal log4shell : Et après ?. Évalué à 3.
Il est possible en effet que la multinational qui m'emploie soit un cas extrême. Je vois le temps qu'on a mis pour avoir 1 fournisseur dans le système, c'était assez décourageant, donc j'imagine pas vraiment faire ça sur 20 à 30 logiciels.
Ensuite, encore une fois, pour une boite plus petite, je ne doute pas que c'est beaucoup plus simple. Une PME va juste faire le virement et basta.
Mais en général, c'est rarement les PME qu'on accuse de profiter du logiciel libre sans rien donner en retour.
Je suppose que le point important, c'est la relation de subordination. À priori, je pense qu'il n'y a pas de relation de subordination entre un projet lambda (gitlab) et un codeur lambda (barmic).
Mais tu as raison de pointer ça, et je pense que c'est une question qui s'inscrit dans la réflexion autour des réseaux sociaux et du travail de création fait par les utilisateurs.
Ton exemple me parait plus équitable que les histoires autour de Facebook, car Gitlab va aussi contribuer au pot commun, même si, comme tu le pointes, c'est un produit d'appel.
[^] # Re: Comme openssl
Posté par Misc (site web personnel) . En réponse au journal log4shell : Et après ?. Évalué à 4.
Mais je n'ai pas dit "une interdiction", j'ai parlé de "c'est pas si simple". C'est rien d'insurmontable, vu qu'on arrive à faire le sponsoring.
Et comme tu le souligne, la boite qui paye doit vérifier, mais vérifier, c'est de la paperasse, et c'est un peu intrusif hélas.
Genre, si demain on dit "on veut te filer des thunes, mais on a besoin de ta carte d'identité pour vérifier ta nationalité", ça va faire grincer des dents à juste titre.
L'exemple du FOSDEM est aussi un bon exemple parce que le FOSDEM est une assoce, c'est établi et le sponsoring est tout les ans. Donc tu fais la paperasse une fois, et ça parait pas louche, et ça va.
Payer des devs une fois, c'est autre chose.
Et je ne parle pas de la question du travail déguisé, parce qu'il y a aussi ce coté intéressant (à savoir que si une boite file de l'argent à X pour faire du travail sur un logiciel Y qui est vendu/utilisé, je comprends que les impôts regardent ça d'un œil bizarre car c'est comme une presta sans payer d’impôts, et les impôts, ils aiment pas ça)
[^] # Re: Isolation des accès réseaux
Posté par Misc (site web personnel) . En réponse au journal log4shell : Et après ?. Évalué à 3.
Oula, faut que je dorme plus, c'était sur la page wikipedia, pas sur freebsd.org. Ou sur https://papers.freebsd.org/2020/linux.conf.au/goodkin_freebsd_the_other_unix-like_os/
[^] # Re: Comme openssl
Posté par Misc (site web personnel) . En réponse au journal log4shell : Et après ?. Évalué à 5.
Alors oui, mais c'est long.
Les États Unis ont un certain nombre de loi fédéral vis à vis de la corruption, notamment le Foreign Corruption Practice Act (loi sur la corruption à l'étranger).
Moi, j'ai la nationalité française, je bosse à Paris, avec un contrat français avec une boite française en temps qu'admin sys. Et pourtant en pratique, ça impacte ma vie professionnelle de plusieurs façons, car mon employeur est filiale de filiale d'une boite aux USA, elle même filiale d'une boite plus grande, aussi aux USA.
Primo, tout les ans, toute la boite a une formation obligatoire sur le sujet du FCPA. C'est une formation sur le web, avec des vidéos, des questions, et ça tombe en hiver. On a aussi une sensibilisation vis à vis du RGPD et de la sécurité.
Pendant des années, ça a été illustré par la même histoire sur la construction d'un stade dans un pays imaginaire, ou quelqu'un sous pression de son sous traitant paye un pot de vin pour finir la construction à temps d'un stade (eg, contourner la demande de permis qui va prendre 4 mois), mais … le stade s'effondre à cause de ça 2 slides plus tard, et c'est mal(tm).
La formation a fini par être refondu (donc avec d'autres histoires) au bout d'un certain temps mais ça avait fini par devenir un meme en interne. Je suis assez fier de faire un score parfait chaque année depuis 5 ans en français ou en anglais, mon objectif est de réussir à faire la formation dans une 3eme langue, car on s'occupe comme on peut.
Secundo, et c'est la ou ça devient intéressant, c'est que les USA sont assez rigide sur la question de la corruption, dans le sens ou ils estiment que si il y a un acte de corruption dans ta chaîne de responsabilité même dans un autre pays, tu es responsable.
Si moi, je paye un pot de vin pour passer la douane plus vite pour aller à Yerevan en Arménie dans le cadre du boulot (histoire arrivé à un collègue dans un autre cadre), alors mon employeur est responsable aux yeux de la justice américaine, et quelqu'un peut aller en taule ou avoir une amende. Je ne sais pas si c'est le cas aussi en France, mais en général, ça surprends pas mal de savoir que les USA considèrent que leur loi s'applique en dehors de leur territoire et sur les non ressortissants.
Autant dire que le consensus sur les 6 niveaux de chef au dessus de moi, tous aux USA, est qu'il ne faut pas tenter le diable, d’où les formations, et des vérifications sur les notes de frais, etc, etc.
Je suis admin sys, donc le risque de filer des pots de vins à un douanier est assez mince. Mais la corruption, vis à vis de la loi des USA, c'est défini de façon assez large, dans le sens ou si ça implique de l'argent et quelqu'un lié à un état, c'est louche.
Par exemple, si je fait un tirage au sort pour gagner un smartphone sur un stand du FOSDEM, et paf, c'est une fonctionnaire espagnole qui gagne, ça peut être vu comme de la corruption. Si je paye un repas avec la carte bleue de la boite à un prof norvégien toujours lors du FOSDEM, ça peut être vu comme de la corruption.
Et surtout, je file du cash ou je fait un virement à un étudiant en doctorat (cad, quelqu'un en France payé par l'état), ça peut être vu comme de la corruption.
Et la ou ça devient encore plus drôle, c'est que c'était déjà assez lourd, mais on a aussi le concept (dont j'ai oublié le nom exact) d'entreprise quasi gouvernemental.
Exemple, EDF. EDF n'est pas le gouvernement français, mais le gouvernement français a la majorité des parts, donc ça compte comme si c'était le gouvernement. Et EDF a des sous traitants, donc techniquement, les sous traitants peuvent compte comme EDF, donc comme des fonctionnaires vis à vis de la loi US anti corruption à l'étranger.
Donc prenons un example. Supposons que Roberta Codeusedelogquatreji, qui travaille bosse pour EDF dans une ESN et qui bosse sur log4j sur son temps libre. Mon employeur ne devrait pas lui faire de virement direct pour soutenir log4j, parce qu'elle bosse pour EDF, et donc on a des vérifications à faire avant pour pas avoir d'emmerde avec la justice des USA.
Je ne dit pas que c'est pas faisable, mais c'est relou. Par exemple, on a maintenant un tableau listant les montants et les circonstances des exceptions (par origine de la personne qui paye et de la personne qui recoit, et du statut de la personne qui recoit et de ou ça se passe et comment ça se passe), et "filer du cash" n'est pas dessus (payer des repas, des goodies, oui), donc il faut demander. Et connaissant la boite, je suppose que ça va aussi vite que d'avoir un laisser passer A-38.
Ça c'est pour le FCPA.
Ensuite vient la question de l'OFAC. C'est l'Office of Foreign Assets Controls, le bureau du contrôle des biens étrangers.
C'est un département du ministère des finances des USA, en charge de faire appliquer des sanctions économiques (parmi tant d'autres). En gros, les ressortissants US n'ont pas le droit d'interagir économiquement avec les gens sur la liste publié par l'OFAC. La liste est sur le site web, un fichier texte de 9 megaoctets avec 6300 entités (personne, entreprise, etc).
Comme la politique étrangère du pays n'est pas caractérisé par sa subtilité, il y a directement des pays sur la liste comme l'Iran, la Corée du nord, la Syrie, etc. Ça a donné des choses comme ici, ici, ici au cours des années.
La liste des sanctions est assez complexe, et change régulièrement. Par exemple, c'est aussi l'OFAC qui fait qu'il est interdit d'importer du matériel produit par de la main d'oeuvre Ouïghour (donc je sens que mon prochain serveur va prendre un peu plus de temps à commander à cause de ça.
Donc techniquement, une boite US qui file des thunes à un dev de log4j qui est un citoyen d'Iran (même vivant à l'étranger) serait dans la merde, car c'est interdit. Et le souci de l'OFAC, c'est que ça dépend directement du président (donc non élu), et qu'ils sont un chouia rigide et pas exactement sympa. De ce que j'ai compris, ça ne va pas changer de si tôt, et personne n'a vraiment envie d'attirer l'attention des impôts en demandant des exceptions.
Ensuite, je ne connais pas la loi française. Je ne doute pas que ça soit plus souple, mais je suppose que faire cracher l'argent à une banque, ç'est aussi non trivial, en partie parce que même une banque française va vouloir respecter la loi US pour ne pas se fermer ce marché ou se faire bloquer l'accès à SWIFT. C'est aussi exactement pour ça que l'Europe a mis en place des choses comme INSTEX, ou des lois visant à protéger les entreprises qui ont une relation commercial avec l'Iran.
Donc voila, c'est la version longue de "on peut pas filer de l'argent n'importe comment sinon des stades risquent de s'effondrer". Je ne doute pas que dans une petite boite, ça se passe autrement, et peut être que c'est juste mon employeur qui est particulièrement prudent. Mais je pense qu'à partir d'une certaine taille, tout le monde devient prudent.
[^] # Re: Comme openssl
Posté par Misc (site web personnel) . En réponse au journal log4shell : Et après ?. Évalué à 2.
Alors je ne doute pas qu'il y a des tas de moyens de contourner le FCPA ou les sanctions de l'OFAC, mais je garde mes compétences spéciales pour les cas spéciaux.
Et si j'en crois les trainings annuels, si je respecte pas la loi à la lettre, y a un stade qui va s'effondrer dans un pays pauvre non spécifié 6 mois après, ou un truc comme ça.
[^] # Re: Isolation des accès réseaux
Posté par Misc (site web personnel) . En réponse au journal log4shell : Et après ?. Évalué à 2.
La trademark, et le fait que personne n'a payé pour la certif.
La vraie question est plus "pourquoi on croit que FreeBSD est plus un Unix que Linux", alors que c'est marqué Unix-like sur la page.
[^] # Re: Isolation des accès réseaux
Posté par Misc (site web personnel) . En réponse au journal log4shell : Et après ?. Évalué à 4.
Alors, ce que tu veux, c'est pas simple. Je veux bien reconnaître que la syntaxe de selinux est pourri, mais même avec une syntaxe moins pourri, ça serait lourd, car la lourdeur ne vient pas que de la syntaxe, mais du fait qu'il faut lister tout les accès, et ça prends du temps, c'est pour ça que les gens ont tendances à ne pas le faire.
Et c'est pas un souci technique, car des méthodes hors SELinux, y en a.
Tu veux filtrer l’accès réseau, tu as iptables (et nftables) en sortie, avec par exemple le match "owner".
Tu veux filter l'http, tu peux mettre un proxy squid en sortie, et mettre des ACL sur la destination.
Tu veux restraindre le FS par application, tu as systemd, avec ProtectHome et tout ce qui va avec (InaccessiblePaths, ReadOnlyPaths, etc, cf systemd.exec
Ou, si tu as de l'argent pour refaire le SI, Openshift (et donc Kubernetes avec les bons réglages) lance les applications sans accès root dans des namespaces séparés, avec un fs en read only (sauf répertoire spécifique explicitement indiqué). Tu peux aussi filtrer en sortie avec les NetworkPolicies.
Et du coup, chaque application qui tourne dans un conteneur doit indiquer les volumes en lecture/écriture, les ports en entrée, et le stockage est normalement séparé par application, donc un peu comme pour Android.
Mais voila, comme android, ça implique de balancer tout le travail déjà fait, ou de bâtir des choses par dessus l'existant. Et il faut gérer la machinerie aussi, bien sur.
Donc des solutions, y en a.
[^] # Re: Tout couper?
Posté par Misc (site web personnel) . En réponse au journal tesla. Évalué à 6.
Alors, je suis d'accord avec l'idée mais mon optimisme ne me permet pas d'envisager un code sans bug à la con.
Et une autre hypothèse aurait pu être un bug matériel qui a aboutit à une erreur sans faire crasher tout le soft (car oui, ça peut aussi arriver).
Ou, Tesla ne déploie pas ses firmwares partout en même temps, et c'était une pre release (style dark deploy à la google) avec un bug à la con, mais la boite ne veut pas le dire.
Je vais pas lister tout la page wikipedia, mais je me souviens de l'histoire de mentir sur les accidents dans ses usines en 2018, donc je sais pas trop si on peut encore donner le bénéfice du doute à la boite.
[^] # Re: La mauvaise foi est humaine
Posté par Misc (site web personnel) . En réponse au journal tesla. Évalué à 4.
Je pense surtout que la question est de savoir qui est responsable.
Autant pour un taxi autonome (exemple, waymo), ç'est la même chose qu'avec un taxi normal (eg, pas le passager), autant c'est plus compliqué quand c'est une voiture privé, et que tu es sans doute moins censé avoir une personne assigné à ta voiture (car c'est aussi l'idée, c'est d'avoir un chauffeur sans avoir à le payer au prix d'un chauffeur maintenant).
[^] # Re: La vraie remise en question
Posté par Misc (site web personnel) . En réponse au journal log4shell : Et après ?. Évalué à 2.
Je pense que les bonnes pratiques maintenant, c'est aussi d'avoir les métriques dispos pour usage via prometheus via HTTP, ou d'être kubernetes-compatible (pour le "readyness probe" et "liveness probe", via HTTP aussi).
Ensuite, c'est peut être après demain dans certains SI, voir la semaine prochaine, quand le passage à la virtualisation sera fini (juste après la migration à RHEL 6)
[^] # Re: La vraie remise en question
Posté par Misc (site web personnel) . En réponse au journal log4shell : Et après ?. Évalué à 8.
Alors au début, je me suis dit pareil.
Mais je sais qu'il y a des gens qui stockent plus que simplement des comptes dans un annuaire LDAP. Avec LDAP, tu as quand même:
- une réplication
- un système d'ACL sur qui peut écrire quoi
- des API pour la majorité des langages
Supposons que tu as une tonne d'application en java (genre 200/300). Pour savoir qui est responsable de ça, tu as besoin d'une liste, et si la liste pouvait être aussi utilisable pour les accès aux serveurs, ça serait pas mal chouette.
Donc tu te dit "on peut mettre chaque appli dans l'annuaire", après tout, il est la, ça te coûte virtuellement rien de plus vu que l'annuaire est déjà "payé" (eg, y a des backups, les ports sont ouverts, y a des ACLs, y a la redondance et la réplication). Et surtout, son uptime, c'est le souci de quelqu'un d'autre, et ça sera son souci que tu l'utilises ou pas.
Mais une fois que tu as ça dans l'annuaire, alors c'est tenant de t'en servir pour savoir par exemple qui recoit les mails quand ça crashe. Parce que oui, log4j permet de faire ça, et donc de faire 1 fichier de config unifié sur toutes les applis qui dit "chaque application qui envoie un message de niveau X va envoyer ça par mail aux gens qui sont listés dans l'annuaire sous le groupe qui correspond au nom de l'application", c'est assez propre, vu que l'info est a un seul endroit.
Autre avantage, tu peux laisser chaque groupe modifier ses préférences de journalisation via LDAP sans donner directement un accès aux serveurs en prod pour toucher la config. Et en fait, sans leur demander d'apprendre à faire du XML, de l'ansible ou autre chose. Quand tu as des gens qui vont et qui viennent, voir qui vont d'un projet à un autre, c'est une solution.
Est ce que ça arrive souvent, je sais pas, je bosse pas dans une banque, et j'ai pas 200 applis java à gerer.
Est ce qu'il y a des tas de façons de faire sans ça, clairement. Des alias mails, une base de données spécifiquement, ou juste embaucher des gens plus cher qui savent faire du XML et du ssh (sans doute non compatible avec "on va réduire le budget" ceci dit).
Et de toute façon, la question n'est pas "pourquoi LDAP ?" en particulier, mais "pourquoi du dynamique ?".
log4j, c'est des logs, mais fondamentalement, les logs, c'est du routage de flux texte. Et si on voit la logique d'avoir la possibilité pour postfix de faire des lookups LDAP, alors je peux imaginer des cas ou ça peut servir aussi pour log4j (cf mes exemples inventés).
[^] # Re: outils et génie logiciel
Posté par Misc (site web personnel) . En réponse au journal log4shell : Et après ?. Évalué à 3.
Je pense que ça va rien changer au fait que certaines infras (à tort ou à raison) sont longues à être mise à jour.
La différence entre log4j et windows, c'est qu'en tant qu'admin, je suis responsable de windows, mais pas forcément de log4j.
Un meilleur exemple serait un logiciel proprio qui n'est pas directement fourni à l'admin. Je sais que l'exemple que je vais donner est pourri, mais je connais pas assez de logiciel proprios.
Prenons qnx. C'est un logiciel qui a du succès, mais c'est en général pas moi en tant qu'admin qui va le mettre à jour, mais le fabricant qui me file un firmware. Si on retire les soucis de mise à jour de firmware (aka, c'est chiant de base), on va être dans le même genre de problématique, à savoir qu'il y a 3 acteurs:
- le fournisseur du composant
- les fournisseurs du logiciel qui utilisent le composant
- l'utilisateur des logiciels.
Ça va être plus long qu'un truc avec 2 acteurs car il y a beaucoup plus de monde.
[^] # Re: Ca vaut ce que ça vaut mais...
Posté par Misc (site web personnel) . En réponse au journal log4shell : Et après ?. Évalué à 3.
Y a beaucoup sur npm, mais l’écosystème python est aussi impacté pas mal via du typosquatting régulier, donc je dirais pas vraiment "la majorité".
À titre semi personnel (semi personnel parce que je garde ça pour le boulot, mais surtout pour ressortir des exemples quand je doit convaincre le reste du monde), j'ai une liste sur l'intranet du boulot avec toute les compromission touchant à du code source sur les infra de logiciel libres et dans mon souvenir, c'était de l'ordre de 1 par mois en 2019/2018, tout projet et type de compromission confondu.
Je devrais la publier de l'autre coté du firewall un jour je suppose.
[^] # Re: La vraie remise en question
Posté par Misc (site web personnel) . En réponse au journal log4shell : Et après ?. Évalué à 2.
Je pense pas que ça soit toujours aussi simple que le résumé de ton prof.
Par exemple, faire changer le mot de passe tout les 6 mois, ç'est clairement moins de confort. Par contre, le gain en sécurité est assez marginal (voir négatif) si j'en croit divers discussions sur le sujet.
Et de surcroit, ça ne dit ni sécurité contre quel type d'attaque, ni confort pour qui ?
Ton exemple de la banque est une bonne illustration, car le manque de confort est ressenti par l'utilisateur, mais le bénéfice de sécurité est surtout pour le bénéfice de la banque (vu que l'utilisateur va être couvert plus ou moins via le jeu des assurances et de la loi).
[^] # Re: La vraie remise en question
Posté par Misc (site web personnel) . En réponse au journal log4shell : Et après ?. Évalué à 5.
Dans ce cas, posons la question, est ce qu'il y avait besoin de log4j, si on suppose qu'on peut toujours faire sans certaines fonctions ?
Après tout, pourquoi ne pas rester à Println ou la lib par défaut de java ?
Quelqu'un a eu besoin de chaque bout de fonctionnalité ajouté à un moment. Quelqu'un l'a codé. Je suppose que c'est grosso modo tout ce qu'il faut.
La maintenance, c'est important, mais je sais aussi que dire "non", c'est en général assez peu populaire comme position, comme j'ai pu le voir sur le projet Ansible quand des modules ont été refusés, comme on a pu le voir lorsque que Debian a décidé de passer à systemd, ou les discussions sur les thèmes de GNOME.
Sans aller loin dans le passé, il suffit de voir il y a une semaine sur Linuxfr la discussion sur le manifest v3 et le fait de retirer des fonctionnalités en cadrant un peu mieux ce qui est faisable ou pas.
Dans le cas de log4j, le souci n'est pas forcément de rajouter le lookup jdni, car de ce que j'ai compris, c'était prévu pour être fait via la configuration sous le contrôle d'un admin. Avoir la configuration des logs centralisés dans LDAP via une syntaxe standard de Java, c'etait pas non plus déconnant.
La question d'activer jdni par défaut ou pas, c'est au niveau de la JVM, et pareil, je suppose que les devs de JVM ont du se dire "si quelqu'un utilise la fonction dans le code, alors c'est implicitement qu'il a besoin de l'utiliser".
On peut se poser la question de la gestion récursive des variables, mais je sais que j'ai déjà eu besoin de ça avec ansible, donc je suis assez sur que d'autres auraient pu en avoir besoin dans d'autres contextes, et qu'un dev aurait pu le rajouter en tout bonne foi.
Et pour l'usage de la réflexivité, je suppose que c'est un pattern important pour java (ou du moins, ça avait l'air important quand j'ai appris java).
Ensuite, il faut aussi rappeler que les lookups JDNI sont maintenant désactivés par défaut sur les JVM d'il y a moins de 3 ans (si je me souviens bien) et surtout qu'il existe un concept de sandbox dans la JVM depuis grosso modo toujours. Sandbox qui n'est semble t'il pas utilisé par la majorité des programmes, car ç'est long à coder. Et qui n'est pas activé par défaut, car ça n'aboutirais que à forcer les gens à retirer dés qu'un truc ne marche pas (cf les tutos partout qui commence par "il faut retirer selinux")
Alors, moins de fonctionnalité, sans doute que oui, mais il faut bien voir que dire "non", c'est mal vu, et que dire non ne retire pas le besoin, et qu'à un moment, tu va commencer à perdre des utilisateurs, puis des contributeurs, et le souci n'a fait que bouger ailleurs.
OpenBSD a moins de fonctions qu'une distro Linux. Mais curieusement, les distros Linux sont massivement plus utilisés.
[^] # Re: Comme openssl
Posté par Misc (site web personnel) . En réponse au journal log4shell : Et après ?. Évalué à 3.
Log4j fait parti de la fondation Apache, donc la structure pour recevoir de l'argent est de facto la (cf son ancien président qui m'a pointé ça quand on a eu la même discussion).
Et il faut avoir l'infrastucture et les procédures pour gérer des failles. C'est amusant de comparer ça avec npm (qui a la fonction, mais aussi des gens pour s'en occuper, d'autant plus depuis le rachat par github et par microsoft), ou avec pypi (qui n'a personne pour faire le taf, ou du moins, qui n'avait personne à temps plein sur la maintenance du logiciel avant, et sans doute des volontaires sur le reste).
Des modèles de financement existent (que ça soit des choses comme Anaconda, les distros commerciales, ou sans doute d'autres), mais j'ai pas le sentiment que "il faut se retreindre à ne prendre que des biblis supportées ou on paye" soit la grande tendance du moment.
[^] # Re: Comme openssl
Posté par Misc (site web personnel) . En réponse au journal log4shell : Et après ?. Évalué à 6.
Ouais, enfin, dans une grande boite, sortir l'argent, c'est pas si simple.
Par exemple, tu fais du libre et tu envoies une facture, mais tu es étudiant en doctorat à Paris ? Mon employeur ne peut sans doute pas te payer, car un doctorant est payé par l'état, et les lois anticorruptions américaines s'appliquent (vis à vis de filer de l'argent aux agents gouvernementaux).
Tu bosse dans l'informatique, et tu envoies des factures à coté de ton taf, je suppose que la clause de non concurrence s'applique, donc sans doute niet aussi.
Et les taxes divers et variés, surtout d'un pays à l'autre, c'est compliqué.
Demander des thunes, c'est pas vraiment trivial.
# Comme openssl
Posté par Misc (site web personnel) . En réponse au journal log4shell : Et après ?. Évalué à 10.
On peut regarder ce qui est arrivé avec Heartbleed et OpenSSL.
OpenBSD a fait un fork de son coté avec LibreSSL, tout comme Google. Amazon a proposé s2n.
C'est aussi une des raisons de la création du Project Zero de Google, d'aprés WP.
À coté, Go a eu sa propre lib, Rust a RusTLS, et les autres sans doute pareil, pour éviter de se servir d'OpenSSL.
La Linux Fundation a crée une initiative pour financer le libre, c'est un peu sa raison d'être.
Grace à ça, OpenSSL a récolté assez d'argent pour financer un dev à temps pleins, le code a été nettoyé, et on a pas eu autant de frayeur depuis. Et on a tous découvert que la crypto, c'est important.
À coté de ça, je n'ai pas entendu parler de la moindre exploitation publique du bug qui a eu un impact. Je ne doute pas que des groupes bien financés (états) ont pu en tirer quelque chose, mais 7 ans après, toujours rien, ce qui personnellement me conforte dans mon opinion vis à vis des soucis de cryptos.
On peut aussi regarder ce qui est arrivé avec Shellshock et bash, cad, rien de notable. Personne n'a lancé de nouveau shell, d'initiative pour financer bash.
Et que je sache, les impacts sur le monde ont été assez mineur aussi. Il y a eu quelque DDos, sans doute divers companies de pentest qui ont pu sortir des rapports à leur client, mais c'est tout. Je ne doute pas que plus de cibles ont été attaqués, mais pas grand monde a changé de posture.
Donc qu'est ce qui va arriver ?
Primo, plus de gens vont regarder log4j, et les logiciels adjacents. Le bundling de code est une leçon qu'on redécouvre régulièrement (CVE-2002-0059, qui a poussé les distros a faire du dynamique, si je me souviens bien), je suppose que ça va continuer.
Le monde du libre ne va pas trop changer. Il y a déjà des outils pour vérifier les dépendances, donc peut être plus de monde vont commencer à regarder ça. Les gens qui n'aiment pas java vont continuer à ne pas aimer java, les gens qui ne pigent rien à la complexité logiciel vont continuer à poster des commentaires, les mainteneurs vont utiliser ça pour dire qu'il faut changer le fonctionnement du financement du libre sans que ça change.
Le monde du dev interne proprio va sans doute continuer à se diviser entre "les gens qui s'en préoccupent et qui filent des moyens", et "le reste". Avec un peu de chance, les gens sans budget vont réussir à avoir une excuse pour avoir du budget.
Le monde des boites commerciales ne va pas changer beaucoup plus ses pratiques, à part que les équipes sécurité vont avoir un slide de plus pour tenter de tirer du pognon. Je ne doute pas que sur les 5 prochaines années, les choses vont aller mieux, mais c'est sans doute un changement commencé y a longtemps.
Et ce qui ne va pas arriver:
On ne va pas beaucoup plus regarder ce qui est embarqué. Ç'était un souci avant, on ne le faisait pas car c'était trop cher, aucune des raisons pour changer ça n'a changé, donc ça va sans doute bouger un peu mais pas d'un coup.
On ne va pas forcément plus verrouiller les programmes. Elastic Search n’était pas vulnérable à l’exécution de code à distance grace à l'usage d'un ContextManager. Mais de ce que j'ai compris, c'est chiant de rajouter ça dans le code, tout comme c'est chiant de faire des politiques SELinux, et chiant de faire un réseau segmenté avec des parefeux, des proxys, etc. Spoiler, ça va toujours être aussi chiant, donc on va pas plus le faire d'un coup.
On ne va pas arrêter de coder en java. Il y a toujours des tonnes de devs, donc c'est toujours aussi facile d'embaucher, donc le code va continuer à être écrit et maintenu.
On ne va pas arrêter d'embarquer tout. Pareil, ça va toujours être plus facile, ça résout des soucis (ou du moins, ça échange des soucis). Tout au plus, on va voir maven obtenir la même fonction que npm (eg, npm audit), et qui va être ignoré, sauf par les gens avec assez de CI/CD.