Posté par barmic 🦦 le 28 décembre 2021 à 00:00. En réponse au lien Go 1.18 Beta : la généricité enfin !. Évalué à  3.
C'est moins une question de trivialité que d'exhaustivité.
Le niveau d'abstraction que tu cherche n'est pas toujours le même. Plus tu es abstrait plus tu gère de cas, mais ça peut être au détriment de l'évolution (tu as moins d'hypothèse sur ton type d'entrée, tu sais moins de choses sur lui) ou de l'utilisabilité (ton utilisateur peu moins se baser sur les types pour comprendre ce que tu attends). Dans un programme, tu es seul utilisateur, tu peux généralement énumérer tous les cas d'usages. Ça change drastiquement la donne.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
Posté par barmic 🦦 le 27 décembre 2021 à 21:17. En réponse au journal log4shell : Et après ?. Évalué à  3.
Unix est un ultime indépassable et non modifiable ? Plan9 et GNU proposent des évolutions ils ne sont pas Unix ? (je n'ai jamais bien compris ce qui fais que linux n'est pas un Unix) Linux a déjà pas mal de choses, mais ça peut être simplifié. Comme les cgroup, avant lxc, docker et systemd (entre autre) ça n'était presque pas utilisé.
Posté par barmic 🦦 le 26 décembre 2021 à 19:54. En réponse à la dépêche .NET 6 est sorti - La version la plus rapide à ce jour. Évalué à  3.
On a encore un bel exemple bien récent, illustrant en pratique ce à quoi s'exposent les naïfs qui se confient dans les mains de puissances pour lesquelles ils ne sont guère plus que des outils quand ils ne sont pas vus comme des parasites.
Ils avaient des explications et ont écouté leur communauté. Des problèmes de gouvernance tu en a aussi dans des projets libres tu sais. On a des exemples encore plus récents et qui n'est pas encore terminé (mais on peut en citer d'autres encore, hein ? regarde tzdata toujours pour cette année). Sachant que la critique qui a était faite à .Net on l'a déjà entendu pour Firefox ce dangereux navigateur qui voit les linuxiens comme des parasites.
Sérieusement, n'y a-t-il pas pléthore d'outils de programmation aux écosystèmes moins dangereux, voire libres[…]
Dont .Net ;)
Posté par barmic 🦦 le 26 décembre 2021 à 16:08. En réponse au journal log4shell : Et après ?. Évalué à  2.
Toujours a émettre des hypothèses sur les personnes qui te répondent.
Posté par barmic 🦦 le 26 décembre 2021 à 13:44. En réponse au journal log4shell : Et après ?. Évalué à  4.
Je ne sais pas trop comment on peut annoncer ça. Ça demande aux parties prenantes de se mettre d'accord sur la façon de travailler, en choisissant des méthodes qui minimisent l'inventaire (développement non livré).
Je ne sais pas trop comment on peut annoncer ça.
Ça demande aux parties prenantes de se mettre d'accord sur la façon de travailler, en choisissant des méthodes qui minimisent l'inventaire (développement non livré).
Ça veut aussi dire que tu n'a aucune fonctionnalité qui demande une semaine de travail ? Je trouve ça fou et il n'y a pas que l'héritage qui peut l'expliquer. Nous on déploie des incrément chaque semaine mais la fonctionnalité de bout en bout tu peut avoir quelques semaines/mois pour l'obtenir (d'autant plus si tu as des incidents à gérer et d'autres qui peuvent arriver avec de hautes priorités).
Pour le 1, même si cela semble assez basique il y a toujours des voix pour s'opposer (parceque c'est “cher”) mais j'ai toujours pensé que c'était important d'avoir ce genre d'environnement à disposition, notamment pour pouvoir faire du ”disaster recovery” et pouvoir garantir à son client qu'on peut recréer toute l'infra en temps fini si besoin.
Je suis d'accord mais chacun met le sens qu'il veut derrière les mots et fais sa tambouille. Sur mon projet on est capable de remonter toute l'infra, c'est à dire déballer les machines, les connecter, installer les OS, plus tout ce dont on a besoin et on connait les prérequis de la salle où installer les machines en alimentation électrique et en connectivité réseau entre autre (on est pas encore multi site). Je ne crois pas que c'est ce que tu entendais par recréer "toute l'infra" et du coup il y a pas mal de choses qui ne sont pas automatisées.
Je le vois un peu comme le fullstack où le côté full de la stack est variable selon à qui tu demande.
Posté par barmic 🦦 le 26 décembre 2021 à 13:30. En réponse au journal log4shell : Et après ?. Évalué à  2.
Bref, perso, je vais m'arrêter là parce que ça ne m'intéresse pas trop d'avoir des conversations avec gens qui cherchent la petite bête plutôt que d'essayer de comprendre le raisonnement de l'autre (ce qui n'empêche pas de ne pas être d'accord par ailleurs).
Dommage que tu le prenne ainsi. Ça faisait réellement plusieurs commentaires que je te pointé un paragraphe qui m'a intrigué et que je ne comprenais pas en te disant que je ne devais pas l'avoir compris.
Mon point c'est que quelque chose de dangereux est devenu super fluide, naturel, sans aucune vérification et sans aucune prise de recul de la part des développeurs.
C'est intéressant de le mettre en lumière comme l'avait fait Ken Thompson dans Reflexions on trusting trust qui est une référence encore aujourd'hui. C'est le jusque boutisme que j'ai cru comprendre qui m'avait fait tiquer.
Posté par barmic 🦦 le 26 décembre 2021 à 11:53. En réponse au journal log4shell : Et après ?. Évalué à  3.
Dans ton premier donc ce n'est plus ce que tu fais ?
Dans mon Ă©quipe (une petite vingtaine)
Une vingtaine je trouve ça énorme par contre, je n'ai jamais travaillé dans une équipe de plus de 10 personnes et ça n'a pas duré longtemps.
Tout toujours testé et un time to market de quelques jours à peine (il faut quand-même concevoir et programmer.)
Je ne sais pas trop comment on peut annoncer ça. Nous on est entre 20 minutes et 3 mois parce que faire un petit changement dans un graphique et permettre de l'AB testing dans une fonctionnalité existante qui du coup impacte tout un pan de ton logiciel, de faire des aller-retours avec les utilisateurs, etc ça n'est pas la même chose.
Dans mon dernier projet (pas exactement “petit”) on avait une chaîne de livraison continue et chaque “push” menait à une exécutions de toute la chaîne de tests (unitaires, intégration, et tout ce qu'on veut).
Les tests d'intégration je trouve ça compliqué.
Posté par barmic 🦦 le 26 décembre 2021 à 10:35. En réponse à la dépêche Python pour la fin de l’année 2021. Évalué à  2.
Pour arriver au résultat, j’ai utilisé l’extension pour Firefox Save as eBook dont j’avais touché deux mots ici-même en septembre 2020 et sélectionné le texte (dépêches plus commentaires) pour chaque dépêche.
Pourquoi ne pas avoir téléchargé les versions epub des dépêches ? C'est une fonctionnalité de linuxfr. Je présume que tu n'aurais pas eu les décorations du site (je n'ai pas de lecteur epub et flemme de lire le source pour vérifier).
Posté par barmic 🦦 le 26 décembre 2021 à 00:27. En réponse au journal log4shell : Et après ?. Évalué à  4. Dernière modification le 26 décembre 2021 à 00:28.
Donc ta prochaine faille c'est jackson ou gson ?
PS: il me semble que System.out est synchronisé ce qui va pas faire du bien aux performances de ton application
Posté par barmic 🦦 le 26 décembre 2021 à 00:26. En réponse au journal log4shell : Et après ?. Évalué à  3.
J'ai du vérifié si c'était la même personne qui avait écrit ça :
Mais pour chaque composant utilisé, il faut être sûr du code existant, sûr de l'équipe et sûr du futur du composant et que l'équipe ne sera jamais gangrénée (on a vu quelques attaques côté npm, où quelqu'un qui paraissait de bonne volonté a repris la maintenance d'un composant largement utilisé pour finalement y inclure une faille volontairement bien après), d'autant qu'on met de plus en plus les composants à jour automatiquement (Dependabot, Renovate).
Puis ça
Ca veut juste dire que certaines pratiques ne sont pas souhaitables et qu'il faut qu'on fasse un peu plus attention à ce qu'on fait en tant que développeurs de composants réutilisés.
Les 2 postés le même jour. Donc on ne fait plus rien tant qu'on est pas sûr du code, des dépendances, des toolchain et que tous les développeurs impliqués sont et seront toujours fiables ou on se contente d'appliquer des bonnes pratiques ?
Je ne comprends vraiment pas ta position. Quant au github actions, tu avais déjà ça avec des plug-ins maven ou de ton IDE (vim et emacs inclus). Les problèmes sont pas fondamentalement nouveau. Ça ne veut pas dire qu'on ne peut rien faire mais qu'on a déjà de la lecture sur le sujet, qu'il y a des contre mesures qui sont mise en place (vscode et intelij par exemple distinguent un code au quel tu fais confiance ou pas). On avait eu un retour ici même de quelqu'un touché par le faux paquet requests sur pip. Après oui ceux qui font n'importe quoi dont n'importe quoi. Maintenant leur responsabilité peut être jugé au tribunal.
Mon point Ă la base, c'est que :
Posté par barmic 🦦 le 25 décembre 2021 à 21:18. En réponse au journal log4shell : Et après ?. Évalué à  2.
J'ai rien compris au paragraphe que j'ai cité plus haut du coup.
Accepter qu'il y ait un risque ne veut pas dire courir comme un poulet sans tête en espérant ne pas taper un mur. Si chacun sur son projet est un peu plus conscient des enjeux, ça améliore de beaucoup la résilience de l'ensemble.
Tu as toujours et tu aura toujours des gens qui font n'importe quoi. C'est pas lié à l'informatique ni à aujourd'hui. La médiatisation de faille comme log4shell et la responsabilisation légale en cas d'incident vont dans ce sens.
Que tout ne soit pas parfait je suis d'accord. Affirmer que rien est fait me semble verser dans l'Ă©motion du moment.
Posté par barmic 🦦 le 25 décembre 2021 à 19:34. En réponse au journal log4shell : Et après ?. Évalué à  4.
Non 1000 fois non ! Jamais ! Tu appel de tes veux à la construction d'une cathédrale, mais ce n'est pas comme ça que ça fonctionne. Ça n'a jamais fonctionner comme ça et ça ne peut pas fonctionner ainsi. Ce que tu souhaite "s'assurer que toutes nouvelles fonctionnalités n'ai aucune faille de sécurité", même allégée parce qu'il est impossible de garantir l'absence de faille, ce serait quoi ? 3 à 5 fois plus d'effort ? Et qui peut le faire les 20 à 30% des développeurs les plus connaisseurs en sécurité ?
Il faut apprendre à vivre avec le fait que ton code, ta toolchain, ton matériel et les gens qui utilisent ton logiciel sont peut être tes ennemis. Le travail c'est de savoir quel est l'enjeu (qu'est-ce que ça implique ?) et d'avoir des contremesures pour (qui auront elles-même des problèmes potentielles, mais qui modifient les probabilités de problèmes ou leur impact).
Il y a pleins de choses qui sont faites, la CI est quelque chose qui s'est extrêmement démocratisé et qui permet la prise en compte rapide, les bug bounty prolifèrent, les systèmes et plateformes se durcissent avec le temps (c'est le cas de java entre autre)…
Ce que tu cherche est délirant :
Il faut faire le deuil de tout cela et accepter que l'informatique n'est pas une science capable de fournir ce niveau de garanti.
Posté par barmic 🦦 le 25 décembre 2021 à 10:43. En réponse au journal log4shell : Et après ?. Évalué à  4.
Un point qui me chagrine est que chaque fois qu'il y a une faille, on dirige plein d'argent et plein de recherche sur le projet qui a posé souci et on perd de vue que c'est un problème général. Tous les jours, on utilise du code Open Source dont on a absolument aucune idée du contenu (le problème est le même pour le code proprio mais on l'utilise moins facilement). On espère que les gens qui le développent savent ce qu'ils font et sont sérieux et honnêtes. Ben pour l'instant, on a eu globalement du bol. Est-ce que ça va durer ?
Je ne suis pas d'accord. Après heartbleed il y a des choses qui ont était faites de manière plus général (il y a FOSSA dont je parlais plus haut, mais la linux fondation aussi avait fais des choses). La question c'est quel projets n'est pas critique pour la sécurité ? Il faut faire des choix.
Par contre ça montre je trouve que des politiques de sécurité drastiques (règle réseau, droits au niveau du système) peuvent être mises en place et peuvent annihiler la dangerosité de nombreuses attaques.
Posté par barmic 🦦 le 25 décembre 2021 à 10:35. En réponse au journal log4shell : Et après ?. Évalué à  3.
Tout à fait d'accord. Un autre élément qui montre que le lookup bien que très surprenant doit avoir des usages, c'est que la principale alternative à log4j : logback, le faisait aussi (bon ça n'est pas accessible depuis le logging).
https://logback.qos.ch/news.html
Posté par barmic 🦦 le 25 décembre 2021 à 02:09. En réponse au lien Violation de la licence GPL d'OBS par Tiktok. Évalué à  8.
Ça n'est pas aussi simple que ça. La Chine est dans l'organisation mondiale du commerce. Et la Chine aussi a besoin que sa propriété intellectuelle ne soit pas bafouée.
Je ne sais pas sur quoi ça va aboutir, mais je ne serais pas si catégorique.
Posté par barmic 🦦 le 25 décembre 2021 à 00:17. En réponse au journal log4shell : Et après ?. Évalué à  10.
Je ne suis pas certains que les failles suivantes auraient été trouvées si vite avec du code non lisible. Et des initiatives comme FOSSA sont bien plus compliquées à mettre en place avec du code fermé. Après on est pas à l'abri de commits hypocrites.
Je ne sais pas si les 2 se valent mais je ne dirais pas que c'est identique.
Posté par barmic 🦦 le 24 décembre 2021 à 21:54. En réponse au journal log4shell : Et après ?. Évalué à  7.
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).
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).
Ça existe :
https://jeremylong.github.io/DependencyCheck/dependency-check-maven/
Posté par barmic 🦦 le 24 décembre 2021 à 21:10. En réponse au journal log4shell : Et après ?. Évalué à  4.
Non mais je sais comment on perd de la connaissance, mais comment vous decretez que c'est le cas ?
Posté par barmic 🦦 le 24 décembre 2021 à 18:19. En réponse au journal log4shell : Et après ?. Évalué à  2.
D'où tu sort que ça signifie qu'ils ne savent pas reconstruire leur logiciel ?
Posté par barmic 🦦 le 24 décembre 2021 à 18:16. En réponse au journal log4shell : Et après ?. Évalué à  8.
Le danger premier de log4shell c'est qu'il est un moyen d'entrée et qu'il est possible de lancer l'attaque de manière générique à l'heure actuel probablement tous les serveurs derrière une IPv4 ont dû prendre une tentative. Quand tu as déjà quelqu'un qui s'est introduit physiquement dans la centrale pour prendre le contrôle d'un serveur, c'est tout à fait possible, mais ce n'est plus à la porté du script kiddy. On commence à entrer dans une séquence de défaillance et plus une seule. Ils ont d'autres contre mesures qui vont encore rendre plus compliqué l'exploitation comme le fait que toutes les connexions doivent avoir étaient autorisée au préalable. Je ne sais pas, mais je doute qu'ils utilisent des jars signés ou de la sécurité type java2.
On est sur des niveaux d'attaques qui sont sans commune mesures avec ce dont on parle pour simplement log4shell.
Posté par barmic 🦦 le 24 décembre 2021 à 15:37. En réponse au journal log4shell : Et après ?. Évalué à  6.
Tout le monde ne peux pas avoir ce genre de fonctionnement. J'ai des amis qui font des logiciels en centrales nucléaires. Leurs installations ne sont pas reliées à internet, les mises à jour ne se font pas via une CI/CD et sans aller jusqu'à ce genre d'extrémum c'est le cas de pas mal de choses en industrie. Parce qu'ils séparent leurs réseaux. Stuxnet n'a pas besoin de log4shell pour te pourrir la vie.
Et sans accès possible distant, log4shell perds beaucoup de sa dangerosité.
Posté par barmic 🦦 le 24 décembre 2021 à 15:31. En réponse au journal log4shell : Et après ?. Évalué à  4.
À coté, Go a eu sa propre lib, Rust a RusTLS, et les autres sans doute pareil, pour éviter de se servir d'OpenSSL.
Je ne sais pas ce qu'il en ai des autres, mais rustls a démarré son développement 2 ans après heartbleed et je ne crois qu'il y ai le moindre lien. rust est simplement très adapté à ce genre d'utilisation. Ce serait dommage de s'en priver.
Posté par barmic 🦦 le 24 décembre 2021 à 11:41. En réponse au journal log4shell : Et après ?. Évalué à  10.
à moyen terme, verrons nous plus d'entreprises contribué à l'open source, ou cesser l'utilisation de l'open source ? Verrons nous une moindre utilisation de java ? la fin des libraires partagées ?
Rien du tout. C'est une tempête dans un verre d'eau. shellshock n'a pas tué linux et heartbleed n'a pas tué OpenSSL. C'est fou cette capacité à oublier que c'est quelque chose de régulier et non pas la fin du monde.
L'open source en question ?
Comme à chaque fois on redécouvre qu'on a laissé 1 à 5 développeurs la charge d'un truc dont beaucoup de monde dépend.
Maven en question ?
C'est pas maven en particulier qui a le moindre problème, c'est la gestion de dépendance. On reproche à maven de ne pas virer les versions incriminer aujourd'hui, on reprochait à npm de permettre de virer des paquets il y a 5 ans. On se détend un peu.
Déjà mettre à jour la bibliothèque n'est pas la seule façon de mitiger la faille. Certains projets pour des raisons qui leurs sont propre ne peuvent pas mettre à jour le code aussi facilement, dans ce cas mettre en place d'autres contremesure (ou avoir toujours eu ses contremesures) fais le taff. Ça n'empêche pas de mettre à jour la bibliothèque, mais pas besoin de le faire dans l'urgence.
Bref je trouve que ça a excité beaucoup de monde qui dans la tempête n'arrive plus à faire la différence entre des éléments de fond et des éléments qui sont justes classiques. Courage à tout ceux qui subissent la tempête.
Pour moi ça questionne plus notre manière de communiquer.
Posté par barmic 🦦 le 23 décembre 2021 à 16:20. En réponse au journal À quoi bon le libre. Évalué à  5.
Arg j'ai réveillé le Z… Tu utilise des mots dont tu ne connaît apparemment pas le sens (enfin j'imagine que tu les tords jusqu'à ce qu'il correspondent à ton besoin). M'enfin…
Oulalala que tu es empathique ! Que je me suis fourvoyé ! Oulala ! Quelle illumination ! Tout ce que tu dis à tellement de sens ! Maintenant que tu l'a répété une 256ème fois c'est devenu limpide ! Un vrai appel à la paix et devrais corriger tous les problèmes de vaccination !
Posté par barmic 🦦 le 23 décembre 2021 à 14:50. En réponse au journal À quoi bon le libre. Évalué à  3.
Je me permet de pointer sur le wiktionnaire pour mieux expliquer ce que je voulais dire.
C'est pire encore tu pense qu'ils tuent volontairement des gens. On est encore plus loin de l'empathie que je ne le croyais.
Soyons clair je ne suis pas antivaxx, je suis vacciné 3 doses et je recommande à toutes personnes qui n'ont pas de contre indication médicales à le faire.
Mais la peur, la crainte ou autre envers les vaccins ne s'inscrit probablement pas dans une volonté de tuer autrui !
Par exemple il semble que les enjeux de collectivité par rapport aux besoins personnel soit quelque chose d'absolument incompréhensible pour une partie de la population. Mais en quelle part c'est leur faute et en quelle part le fait qu'on présente toujours que des individualités (dans tout : en politique, dans le sport, dans la pop culture,…) ?
C'est un exemple, mais vraiment ta manière de présenter les choses n'amène qu'à une chose : leur stigmatisation ne les poussera pas à se faire vacciner. Ça pousse à les discriminer potentiellement violemment.
Je ne vois aucune forme d'empathie là dedans (et non je n'amalgame pas empathie et bienveillance), mais une dérive très problématique.
[^] # Re: Trou de mémoire
Posté par barmic 🦦 . En réponse au lien Go 1.18 Beta : la généricité enfin !. Évalué à  3.
C'est moins une question de trivialité que d'exhaustivité.
Le niveau d'abstraction que tu cherche n'est pas toujours le même. Plus tu es abstrait plus tu gère de cas, mais ça peut être au détriment de l'évolution (tu as moins d'hypothèse sur ton type d'entrée, tu sais moins de choses sur lui) ou de l'utilisabilité (ton utilisateur peu moins se baser sur les types pour comprendre ce que tu attends). Dans un programme, tu es seul utilisateur, tu peux généralement énumérer tous les cas d'usages. Ça change drastiquement la donne.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Isolation des accès réseaux
Posté par barmic 🦦 . En réponse au journal log4shell : Et après ?. Évalué à  3.
Unix est un ultime indépassable et non modifiable ? Plan9 et GNU proposent des évolutions ils ne sont pas Unix ? (je n'ai jamais bien compris ce qui fais que linux n'est pas un Unix) Linux a déjà pas mal de choses, mais ça peut être simplifié. Comme les cgroup, avant lxc, docker et systemd (entre autre) ça n'était presque pas utilisé.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Publicité mensongère éhontée ?!!
Posté par barmic 🦦 . En réponse à la dépêche .NET 6 est sorti - La version la plus rapide à ce jour. Évalué à  3.
Ils avaient des explications et ont écouté leur communauté. Des problèmes de gouvernance tu en a aussi dans des projets libres tu sais. On a des exemples encore plus récents et qui n'est pas encore terminé (mais on peut en citer d'autres encore, hein ? regarde tzdata toujours pour cette année). Sachant que la critique qui a était faite à .Net on l'a déjà entendu pour Firefox ce dangereux navigateur qui voit les linuxiens comme des parasites.
Dont .Net ;)
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: La vraie remise en question
Posté par barmic 🦦 . En réponse au journal log4shell : Et après ?. Évalué à  2.
Toujours a émettre des hypothèses sur les personnes qui te répondent.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: L'opensource et maven fonctionne très bien
Posté par barmic 🦦 . En réponse au journal log4shell : Et après ?. Évalué à  4.
Ça veut aussi dire que tu n'a aucune fonctionnalité qui demande une semaine de travail ? Je trouve ça fou et il n'y a pas que l'héritage qui peut l'expliquer. Nous on déploie des incrément chaque semaine mais la fonctionnalité de bout en bout tu peut avoir quelques semaines/mois pour l'obtenir (d'autant plus si tu as des incidents à gérer et d'autres qui peuvent arriver avec de hautes priorités).
Je suis d'accord mais chacun met le sens qu'il veut derrière les mots et fais sa tambouille. Sur mon projet on est capable de remonter toute l'infra, c'est à dire déballer les machines, les connecter, installer les OS, plus tout ce dont on a besoin et on connait les prérequis de la salle où installer les machines en alimentation électrique et en connectivité réseau entre autre (on est pas encore multi site). Je ne crois pas que c'est ce que tu entendais par recréer "toute l'infra" et du coup il y a pas mal de choses qui ne sont pas automatisées.
Je le vois un peu comme le fullstack où le côté full de la stack est variable selon à qui tu demande.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Ca vaut ce que ça vaut mais...
Posté par barmic 🦦 . En réponse au journal log4shell : Et après ?. Évalué à  2.
Dommage que tu le prenne ainsi. Ça faisait réellement plusieurs commentaires que je te pointé un paragraphe qui m'a intrigué et que je ne comprenais pas en te disant que je ne devais pas l'avoir compris.
C'est intéressant de le mettre en lumière comme l'avait fait Ken Thompson dans Reflexions on trusting trust qui est une référence encore aujourd'hui. C'est le jusque boutisme que j'ai cru comprendre qui m'avait fait tiquer.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: L'opensource et maven fonctionne très bien
Posté par barmic 🦦 . En réponse au journal log4shell : Et après ?. Évalué à  3.
Dans ton premier donc ce n'est plus ce que tu fais ?
Une vingtaine je trouve ça énorme par contre, je n'ai jamais travaillé dans une équipe de plus de 10 personnes et ça n'a pas duré longtemps.
Je ne sais pas trop comment on peut annoncer ça. Nous on est entre 20 minutes et 3 mois parce que faire un petit changement dans un graphique et permettre de l'AB testing dans une fonctionnalité existante qui du coup impacte tout un pan de ton logiciel, de faire des aller-retours avec les utilisateurs, etc ça n'est pas la même chose.
Les tests d'intégration je trouve ça compliqué.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
# epub
Posté par barmic 🦦 . En réponse à la dépêche Python pour la fin de l’année 2021. Évalué à  2.
Pourquoi ne pas avoir téléchargé les versions epub des dépêches ? C'est une fonctionnalité de linuxfr. Je présume que tu n'aurais pas eu les décorations du site (je n'ai pas de lecteur epub et flemme de lire le source pour vérifier).
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: La vraie remise en question
Posté par barmic 🦦 . En réponse au journal log4shell : Et après ?. Évalué à  4. Dernière modification le 26 décembre 2021 à 00:28.
Donc ta prochaine faille c'est jackson ou gson ?
PS: il me semble que System.out est synchronisé ce qui va pas faire du bien aux performances de ton application
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Ca vaut ce que ça vaut mais...
Posté par barmic 🦦 . En réponse au journal log4shell : Et après ?. Évalué à  3.
J'ai du vérifié si c'était la même personne qui avait écrit ça :
Puis ça
Les 2 postés le même jour. Donc on ne fait plus rien tant qu'on est pas sûr du code, des dépendances, des toolchain et que tous les développeurs impliqués sont et seront toujours fiables ou on se contente d'appliquer des bonnes pratiques ?
Je ne comprends vraiment pas ta position. Quant au github actions, tu avais déjà ça avec des plug-ins maven ou de ton IDE (vim et emacs inclus). Les problèmes sont pas fondamentalement nouveau. Ça ne veut pas dire qu'on ne peut rien faire mais qu'on a déjà de la lecture sur le sujet, qu'il y a des contre mesures qui sont mise en place (vscode et intelij par exemple distinguent un code au quel tu fais confiance ou pas). On avait eu un retour ici même de quelqu'un touché par le faux paquet requests sur pip. Après oui ceux qui font n'importe quoi dont n'importe quoi. Maintenant leur responsabilité peut être jugé au tribunal.
Mon point Ă la base, c'est que :
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Ca vaut ce que ça vaut mais...
Posté par barmic 🦦 . En réponse au journal log4shell : Et après ?. Évalué à  2.
J'ai rien compris au paragraphe que j'ai cité plus haut du coup.
Tu as toujours et tu aura toujours des gens qui font n'importe quoi. C'est pas lié à l'informatique ni à aujourd'hui. La médiatisation de faille comme log4shell et la responsabilisation légale en cas d'incident vont dans ce sens.
Que tout ne soit pas parfait je suis d'accord. Affirmer que rien est fait me semble verser dans l'Ă©motion du moment.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Ca vaut ce que ça vaut mais...
Posté par barmic 🦦 . En réponse au journal log4shell : Et après ?. Évalué à  4.
Non 1000 fois non ! Jamais ! Tu appel de tes veux à la construction d'une cathédrale, mais ce n'est pas comme ça que ça fonctionne. Ça n'a jamais fonctionner comme ça et ça ne peut pas fonctionner ainsi. Ce que tu souhaite "s'assurer que toutes nouvelles fonctionnalités n'ai aucune faille de sécurité", même allégée parce qu'il est impossible de garantir l'absence de faille, ce serait quoi ? 3 à 5 fois plus d'effort ? Et qui peut le faire les 20 à 30% des développeurs les plus connaisseurs en sécurité ?
Il faut apprendre à vivre avec le fait que ton code, ta toolchain, ton matériel et les gens qui utilisent ton logiciel sont peut être tes ennemis. Le travail c'est de savoir quel est l'enjeu (qu'est-ce que ça implique ?) et d'avoir des contremesures pour (qui auront elles-même des problèmes potentielles, mais qui modifient les probabilités de problèmes ou leur impact).
Il y a pleins de choses qui sont faites, la CI est quelque chose qui s'est extrêmement démocratisé et qui permet la prise en compte rapide, les bug bounty prolifèrent, les systèmes et plateformes se durcissent avec le temps (c'est le cas de java entre autre)…
Ce que tu cherche est délirant :
Il faut faire le deuil de tout cela et accepter que l'informatique n'est pas une science capable de fournir ce niveau de garanti.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Ca vaut ce que ça vaut mais...
Posté par barmic 🦦 . En réponse au journal log4shell : Et après ?. Évalué à  4.
Je ne suis pas d'accord. Après heartbleed il y a des choses qui ont était faites de manière plus général (il y a FOSSA dont je parlais plus haut, mais la linux fondation aussi avait fais des choses). La question c'est quel projets n'est pas critique pour la sécurité ? Il faut faire des choix.
Par contre ça montre je trouve que des politiques de sécurité drastiques (règle réseau, droits au niveau du système) peuvent être mises en place et peuvent annihiler la dangerosité de nombreuses attaques.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: La vraie remise en question
Posté par barmic 🦦 . En réponse au journal log4shell : Et après ?. Évalué à  3.
Tout à fait d'accord. Un autre élément qui montre que le lookup bien que très surprenant doit avoir des usages, c'est que la principale alternative à log4j : logback, le faisait aussi (bon ça n'est pas accessible depuis le logging).
https://logback.qos.ch/news.html
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Mictioner sur un violon
Posté par barmic 🦦 . En réponse au lien Violation de la licence GPL d'OBS par Tiktok. Évalué à  8.
Ça n'est pas aussi simple que ça. La Chine est dans l'organisation mondiale du commerce. Et la Chine aussi a besoin que sa propriété intellectuelle ne soit pas bafouée.
Je ne sais pas sur quoi ça va aboutir, mais je ne serais pas si catégorique.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: outils et génie logiciel
Posté par barmic 🦦 . En réponse au journal log4shell : Et après ?. Évalué à  10.
Je ne suis pas certains que les failles suivantes auraient été trouvées si vite avec du code non lisible. Et des initiatives comme FOSSA sont bien plus compliquées à mettre en place avec du code fermé. Après on est pas à l'abri de commits hypocrites.
Je ne sais pas si les 2 se valent mais je ne dirais pas que c'est identique.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Comme openssl
Posté par barmic 🦦 . En réponse au journal log4shell : Et après ?. Évalué à  7.
Ça existe :
https://jeremylong.github.io/DependencyCheck/dependency-check-maven/
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: L'opensource et maven fonctionne très bien
Posté par barmic 🦦 . En réponse au journal log4shell : Et après ?. Évalué à  4.
Non mais je sais comment on perd de la connaissance, mais comment vous decretez que c'est le cas ?
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: L'opensource et maven fonctionne très bien
Posté par barmic 🦦 . En réponse au journal log4shell : Et après ?. Évalué à  2.
D'où tu sort que ça signifie qu'ils ne savent pas reconstruire leur logiciel ?
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: L'opensource et maven fonctionne très bien
Posté par barmic 🦦 . En réponse au journal log4shell : Et après ?. Évalué à  8.
Le danger premier de log4shell c'est qu'il est un moyen d'entrée et qu'il est possible de lancer l'attaque de manière générique à l'heure actuel probablement tous les serveurs derrière une IPv4 ont dû prendre une tentative. Quand tu as déjà quelqu'un qui s'est introduit physiquement dans la centrale pour prendre le contrôle d'un serveur, c'est tout à fait possible, mais ce n'est plus à la porté du script kiddy. On commence à entrer dans une séquence de défaillance et plus une seule. Ils ont d'autres contre mesures qui vont encore rendre plus compliqué l'exploitation comme le fait que toutes les connexions doivent avoir étaient autorisée au préalable. Je ne sais pas, mais je doute qu'ils utilisent des jars signés ou de la sécurité type java2.
On est sur des niveaux d'attaques qui sont sans commune mesures avec ce dont on parle pour simplement log4shell.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: L'opensource et maven fonctionne très bien
Posté par barmic 🦦 . En réponse au journal log4shell : Et après ?. Évalué à  6.
Tout le monde ne peux pas avoir ce genre de fonctionnement. J'ai des amis qui font des logiciels en centrales nucléaires. Leurs installations ne sont pas reliées à internet, les mises à jour ne se font pas via une CI/CD et sans aller jusqu'à ce genre d'extrémum c'est le cas de pas mal de choses en industrie. Parce qu'ils séparent leurs réseaux. Stuxnet n'a pas besoin de log4shell pour te pourrir la vie.
Et sans accès possible distant, log4shell perds beaucoup de sa dangerosité.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Comme openssl
Posté par barmic 🦦 . En réponse au journal log4shell : Et après ?. Évalué à  4.
Je ne sais pas ce qu'il en ai des autres, mais rustls a démarré son développement 2 ans après heartbleed et je ne crois qu'il y ai le moindre lien. rust est simplement très adapté à ce genre d'utilisation. Ce serait dommage de s'en priver.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
# Non
Posté par barmic 🦦 . En réponse au journal log4shell : Et après ?. Évalué à  10.
Rien du tout. C'est une tempête dans un verre d'eau. shellshock n'a pas tué linux et heartbleed n'a pas tué OpenSSL. C'est fou cette capacité à oublier que c'est quelque chose de régulier et non pas la fin du monde.
Comme à chaque fois on redécouvre qu'on a laissé 1 à 5 développeurs la charge d'un truc dont beaucoup de monde dépend.
C'est pas maven en particulier qui a le moindre problème, c'est la gestion de dépendance. On reproche à maven de ne pas virer les versions incriminer aujourd'hui, on reprochait à npm de permettre de virer des paquets il y a 5 ans. On se détend un peu.
Déjà mettre à jour la bibliothèque n'est pas la seule façon de mitiger la faille. Certains projets pour des raisons qui leurs sont propre ne peuvent pas mettre à jour le code aussi facilement, dans ce cas mettre en place d'autres contremesure (ou avoir toujours eu ses contremesures) fais le taff. Ça n'empêche pas de mettre à jour la bibliothèque, mais pas besoin de le faire dans l'urgence.
Bref je trouve que ça a excité beaucoup de monde qui dans la tempête n'arrive plus à faire la différence entre des éléments de fond et des éléments qui sont justes classiques. Courage à tout ceux qui subissent la tempête.
Pour moi ça questionne plus notre manière de communiquer.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Praticiens
Posté par barmic 🦦 . En réponse au journal À quoi bon le libre. Évalué à  5.
Arg j'ai réveillé le Z… Tu utilise des mots dont tu ne connaît apparemment pas le sens (enfin j'imagine que tu les tords jusqu'à ce qu'il correspondent à ton besoin). M'enfin…
Oulalala que tu es empathique ! Que je me suis fourvoyé ! Oulala ! Quelle illumination ! Tout ce que tu dis à tellement de sens ! Maintenant que tu l'a répété une 256ème fois c'est devenu limpide ! Un vrai appel à la paix et devrais corriger tous les problèmes de vaccination !
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Praticiens
Posté par barmic 🦦 . En réponse au journal À quoi bon le libre. Évalué à  3.
C'est pire encore tu pense qu'ils tuent volontairement des gens. On est encore plus loin de l'empathie que je ne le croyais.
Soyons clair je ne suis pas antivaxx, je suis vacciné 3 doses et je recommande à toutes personnes qui n'ont pas de contre indication médicales à le faire.
Mais la peur, la crainte ou autre envers les vaccins ne s'inscrit probablement pas dans une volonté de tuer autrui !
Par exemple il semble que les enjeux de collectivité par rapport aux besoins personnel soit quelque chose d'absolument incompréhensible pour une partie de la population. Mais en quelle part c'est leur faute et en quelle part le fait qu'on présente toujours que des individualités (dans tout : en politique, dans le sport, dans la pop culture,…) ?
C'est un exemple, mais vraiment ta manière de présenter les choses n'amène qu'à une chose : leur stigmatisation ne les poussera pas à se faire vacciner. Ça pousse à les discriminer potentiellement violemment.
Je ne vois aucune forme d'empathie là dedans (et non je n'amalgame pas empathie et bienveillance), mais une dérive très problématique.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll