Alors que pour beaucoup, nous bossons sur la correction de la CVE concernant log4j en mode pompiers, je me suis demandé quelles seront les conséquences à moyen terme de cette faille.
1- Rappelons la CVE: log4j <2.16 a un énorme trou de sécurité, facile à mitiger
2- log4j est utilisé dans presque tous les projets java
3- log4j est maintenu par 4 honorable personnes contributrices
4- Cela est arrivé lors de la période de fin d'année où les personnes sont en vacances ou sont fatiguées
La difficulté est ici le périmètre d'action de log4j : Ce module maven est présent quasiment partout, chez presque tous les logiciels java, il sera quasiment impossible de tout scanner.Après l'armée Belge , il est envisageable de penser que d'autres entités se feront pirater.
L'open source en question ?
Délivré sous license apache, log4j est opensource, et donc il est simple pour un projet java de l'utiliser. Hors , en cas de failles, on ne peux compter que sur le courage de quelques contributeurs, mettant ainsi ,pour certains, un gros plan sur un problème : quid du support et des correctifs dans les projets open source: les contributeurs aurait très bien pu s'epargner des nuits sans sommeil et laisser tel quel , la mitigation étant donné.
Je vois plutôt ce problème comme une faille chez les éditeurs, je me demande encore pourquoi peu d'éditeurs ont fournit de la main d'œuvre pour corriger la faille. Concernant les logiciels très utilisé sous linux, je pense à eclipse, dbeaver et mindustry
https://hitechglitz.com/france/ce-que-log4shell-nous-apprend-sur-la-securite-open-source/
Maven en question ?
Maven est un moyen de construire les projets java. En simplifiant, il prends un fichier pom, un fiichier de setting, un fichier source et construit le projet, en téléchargent les modules présent dans le fichier pom depuis maven-central (entre autre) et en les mettant dans un repertoire m2 .
Ce fichier pom peux donc faire appel à toutes les libraires maven , y compris log4j troué.
Nexus a recemment trouvé que 40% des projets maven utilisent eencore un log4j troué, sans doute des projets abandonné , comme l'ont pu l'être ssh-ganymede par le passé.
Faut il que maven-central fasse le ménage dans ses projets au risque de se voir remplacé ? Et encore, je ne suis pas sûr qu'en utilisant pip en remplacement, cela donne un résultat différent
https://www.globenewswire.com/news-release/2021/12/22/2357089/0/en/Critical-Log4j-Vulnerability-Still-Being-Downloaded-40-of-the-Time-Sonatype-Research-Reveals-in-New-Resource-Center.html
**
l'omniprésence de java en question ?**
Le problème de log4shell est son prérimètre, toutes les applis java peuvent avoir un log4j dans ses classes. Nombreuses entités ont tout misé sur java , et même la politique d'oracle ne les ont pas arrêtés, car ils ont migré vers de l'openjdk (openjdk distro, zulu adopt etc…)
à 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 ?
# outils et génie logiciel
Posté par Benoît Sibaud (site web personnel) . Évalué à 10.
Notons aussi que les outils d'analyse de code statique ou dynamique, libres ou propriétaires, sur du source disponible ou du bytecode, aussi sophistiqués qu'ils soient, n'ont rien vu. Ni les précédents audit de sécurité, relectures, pentests, tests de fuzzing, etc. sur n'importe quel logiciel embarquant des versions vulnérables de log4j, que ce logiciel soit propriétaire ou non. Dit autrement on peut vouloir blâmer la maigre équipe log4j qui a pourtant réagi rapidement, mais personne n'a fait mieux, y compris chez les très gros éditeurs de logiciels ou les grands acteurs de la sécurité. Un peu comme si on blâmait juste l'équipe d'openssl utilisé tout le monde alors que personne n'avait rien vu venir non plus. Et que personne n'a d'inventaire exhaustif de son parc logiciel, que tout le monde a des logiciels n'ayant plus aucun support sécu, que les flux vers l'extérieur sont largement ouverts, sans parler du fait que les donneurs de conseil de maintenant et les colporteurs d'infos approximatives ou erronées sont les mêmes que ceux ayant fait ou non-fait les choix informatiques précédents. Bonnes fêtes de fin d'année aux équipes qui doivent continuer à pat cher.
[^] # Re: outils et génie logiciel
Posté par Eh_Dis_Mwan . Évalué à 10.
Globalement, déjà , je ne suis pas sûr que blamer quelqu'un , surtout sur un telle faille, soit vraiment bénéfique. Seuls les paresseux ne laissent passer aucune faille.
Courage aux quelques developpeurs sans vacances pour créer les patches sans regression
Courage aux customer services pour se prendre les foudres et pressions des admins
Soutien aux admins sous pressiondes infosecs qui doivent être pas loin du burn out à defaut de Burnhaupt
et courage aux admins qui refusent de patcher pour garder leur uptime car ne se sentant pas concernés
[^] # Re: outils et génie logiciel
Posté par pasBill pasGates . Évalué à 2. Dernière modification le 24 décembre 2021 à 23:49.
Il n'y va aucun blâme à donner à qui que ce soit. Les failles celà arrive à tout le monde.
De mon point de vue c'est simplement un énième exemple du fait que le code ouvert n'est en rien différent du code propriétaire niveau sécurité.
[^] # Re: outils et génie logiciel
Posté par barmic 🦦 . É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: outils et génie logiciel
Posté par Benoît Sibaud (site web personnel) . Évalué à 9. Dernière modification le 25 décembre 2021 à 09:36.
Quand bien même tu aurais raison sur une telle absence de différence (et je ne suis pas convaincu par ton affirmation dans le contexte mais peu importe), elle ne concerne que la découverte de failles. Reste ensuite la vitesse de correction, la capacité à corriger (par n'importe qui ou non par exemple), l'apprentissage de ses erreurs, etc. pour lesquels la nature juridique du code (et la publicité/ visibilité) me semble avoir un effet.
[^] # Re: outils et génie logiciel
Posté par Eh_Dis_Mwan . Évalué à 2.
Le fait que ce soit du code ouvert a permis une correction plus rapide.
Néanmoins , le fait que cela ne coûte pas 50k la licence a fait que c'est utilisé dans de nombreux logiciels, et de ce fait, même si la correction a été rapide (la mitigation presque instantané) , l'appliquer prendra du temps.
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
[^] # Re: outils et génie logiciel
Posté par Misc (site web personnel) . É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: outils et génie logiciel
Posté par pasBill pasGates . Évalué à 0. Dernière modification le 28 décembre 2021 à 23:30.
Vitesse de correction : ah ben ouais ils ont vite corrigé. Bon ils n'ont fait aucune recherche de variantes ce qui fait qu'on en est au 3 ou 4eme patch de suite a installer en deux semaines mais tout va bien ! Non cette prétendue différence de vitesse est principalement due aux gens qui ne comprennent pas ce que les éditeurs proprios font et croient qu'ils traînent des pieds.
Tout le monde peut corriger : c'est une belle théorie, bon en pratique cela importe peu mais la théorie est belle.
Pourquoi cela importe peu ? Parce que soit les mainteneurs sont responsifs pour les patchs propose et sans ce cas pour l'énorme majorité des bugs ils auront de toute façon déjà fait le correctif car pour la plupart ils sont petits, soit ils ne sont pas responsifs aux patchs envoyé et dans ce cas ben le patch ne va nulle part, et personne ne veut de gérer des forks.
Alors des différences ? Oui sûrement, mais minimes. Rien de fondamental.
[^] # Re: outils et génie logiciel
Posté par barmic 🦦 . Évalué à 6.
C'est mesquin d'entretenir le flou pour les pourrir. Ils ont eu 4 CVE :
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: outils et génie logiciel
Posté par pasBill pasGates . Évalué à 2.
J'ai passé ma carrière à gérer des reports de failles à Microsoft.
Tous ces cas auraient été couvert dans la recherche de variantes, le seul cas qui ne l'aurait pas été est le CVE relatif à un changement dans le fichier de config parce que l'on aurait considéré ce cas peu important (ai tu peux modifier le fichier config tu peux probablement faire bcp de mauvaises choses)
[^] # Re: outils et génie logiciel
Posté par barmic 🦦 . Évalué à 5. Dernière modification le 29 décembre 2021 à 01:44.
Sur une faille 0day tu travail forcément dans l'urgence. Vaut-il mieux fournir une correction partielle au plus vite ou une correction parfaite quelques jours plus tard.
Ils sont 4 (ce qui n'a rien à voir avec le fais que le code soit libre ou non) c'est forcément pas la même ambiance qu'une boîte énorme qui s'est déjà mangé des CVE dont des 0 day à foison (ce qui n'a toujours pas de rapport avec le libre).
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: outils et génie logiciel
Posté par pasBill pasGates . Évalué à 1. Dernière modification le 29 décembre 2021 à 02:21.
100% d'accord et je ne les blames absolument pas, au contraire je les plains !
Non le problème c'est pas eux, ils font ce qu'ils peuvent. Le problème c'est les gens qui assument que ce projet a des pouvoirs magiques niveau gestion des failles simplement du fait de sa licence.
[^] # Re: outils et génie logiciel
Posté par marsu . Évalué à 0.
Mon avis tient en une stratégie :
1- mitigé la faille au plus vite
2- se tourner vers un spécialiste pour auditer le code ( test absurde et de limites)
3- sécuriser le code depuis les résultats de l'audit
4- soumettre le patch à un nouvel audit
5- publier avec la sortie du patch vérifié
Un spécialiste, ça coûte des sous ou de la bonne volonté.
[^] # Re: outils et génie logiciel
Posté par Gil Cot ✔ (site web personnel, Mastodon) . Évalué à 1.
Dommage que tu n'as pas géré le passage à 2022 de ms Exchange.
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
[^] # Re: outils et génie logiciel
Posté par barmic 🦦 . Évalué à 3.
Une cinquième vient d'être publiée. Toujours lié à jndi, mais uniquement si on utilise l'appender jdbc (c'est pour envoyer ses logs dans une base de données relationnelles pour ceux qui ne savent pas).
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: outils et génie logiciel
Posté par srb (site web personnel) . Évalué à 3.
Supposer que les éditeurs proprios font toujours des corrections lentes mais de qualité me semble optimiste. Certains éditeurs de jeux sont spécialistes des séries de patchs après la sortie commerciale d'un jeu.
De même, lorsqu'un éditeur proprio sort un correctif en urgence (suite à une faille zero day par exemple), on ne peut pas en déduire qu'il sera forcément mauvais.
[^] # Re: outils et génie logiciel
Posté par pasBill pasGates . Évalué à 1. Dernière modification le 31 décembre 2021 à 20:45.
Mais tu ne comprends pas ce que je dis.
Le problème n'est pas ce que ce projet a fait. Le problème c'est les gens qui prennent leur vitesse de correction et la comparent à quelque chose de fondamentalement différent.
N'importe quelle boîte est capable de changer deux lignes dans son code et sortir une nouvelle version en une heure si ils ne font pas de tests, pas de recherche de variantes, etc… Certains le font d'ailleurs dans les cas d'urgence.
Le truc est que les boîtes pour beaucoup font des tests significatifs, du moins les grands éditeurs, et on se retrouve avec des gens qui comparent la vitesse de sortie d'un patch peu testé, sans recherche de variantes, avec des patchs qui ont subi une batterie de tests énorme et qui ensuite viennent clamer que le monde OSS patche plus vite, ce qui est ridicule comme comparaison.
[^] # Re: outils et génie logiciel
Posté par barmic 🦦 . Évalué à 7.
Oui mais pour le coup c'est toi qui reproche l'absence de de recherche de variations sur une faille 0 day. Ça peut être totalement assumé pour limiter la faille le plus tôt possible au plus grand nombre quitte à avoir une série de corrections qui suivent. Sachant que la faille était activement exploitée ça ne me paraît pas un choix déconnant.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: outils et génie logiciel
Posté par pasBill pasGates . Évalué à 5.
C'est pas un reproche car il n'y a pas de solution miracle. Ils ont choisi un chemin, correctif rapide mais incomplet, qui a ses avantages et inconvénients. Un autre chemin, correctif plus lent mais plus complet, a ses propres avantages et inconvénients.
Le truc étant de ne pas comparer les deux sur une seule dimension : le temps.
De nouveau le problème n'est pas ce que ce projet a fait mais ce que certains comparent.
# Non
Posté par barmic 🦦 . É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: Non
Posté par savitzkaia . Évalué à 3.
J'allais écrire quelque chose mais tu as dit tout ce que je pensais. Merci à toi!
# Comme openssl
Posté par Misc (site web personnel) . É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.
[^] # Re: Comme openssl
Posté par Krunch (site web personnel) . Évalué à 6.
J'aime bien l'idée de https://blog.filippo.io/professional-maintainers/
TL;DR: si tu fais du Libre, envois des facture à tes utilisateurs commerciaux : il y en a qui sont plus ou moins prêt à payer mais il faut qu'ils reçoivent une facture
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
[^] # Re: Comme openssl
Posté par Misc (site web personnel) . É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.
[^] # Re: Comme openssl
Posté par _kaos_ . Évalué à 7.
Quand je vois les coûts des licences proprios, je dirais que si. Ou les factures de restau parce que hop, c'est bien pour la cohésion d'équipe.
Juste il n'y a pas de ligne dans le budget prévisionnel. Donc rien à imputer. Donc rien qui ne peut sortir.
Le problème est bien plus culturel qu'autre chose. C'est une des raisons pour laquelle je ne met plus la gratuité comme argument fort quand je parle du libre, sauf si ça soutient un autre argument fort, comme la mise à disposition à tous, sans condition de ressources par exemple.
C'est un boulot à part entière, et il est rare que les développeurs aient envie de le faire (des deux côtés : tant en tant que fournisseurs qu'utilisateurs de solutions).
Matricule 23415
[^] # Re: Comme openssl
Posté par Krunch (site web personnel) . Évalué à 3.
Tu montes une boite/association qui envoie la facture en son nom.
Ça varie beaucoup selon le contrat de travail et la juridiction. Mais a priori si tu peux garder le copyright sur ton projet Libre, tu peux sans doute faire payer pour aussi (IANAL, j'ai jamais travaillé en France, DYOR).
Certes. Mais bien souvent c'est « juste » de la paperasse à régler. L'article suggère de régler cet aspect administratif de manière à pouvoir plus facilement aller demander de l'argent là où il est. Je comprend bien que c'est pas faisable pour tout le monde mais il y a vraisemblablement plein de cas où ça aiderait beaucoup.
Exemple personnel : cette année j'ai voulu faire un don à un projet. Ils n'ont pas de page de don ni d'entité légale. J'ai fini par échanger des mails avec le dev principal pour obtenir son IBAN et lui faire un virement. Je sais pas combien d'utilisateurs ils ont mais c'est pas trivial (4000 étoiles sur github, plusieurs centaines de serveurs) et AFAICT les 5 devs principaux font ça sur leur temps libre. Sans aller jusqu'à facturer des entreprises, ils pourraient sans doute financer au moins quelques jours de dev par an juste en ayant une page de dons.
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
[^] # Re: Comme openssl
Posté par Misc (site web personnel) . É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: Comme openssl
Posté par barmic 🦦 . Évalué à 3.
Euh tu peux expliciter le problème ?
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Comme openssl
Posté par Misc (site web personnel) . É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 barmic 🦦 . Évalué à 3.
Je comprends, mais c'est pas le problème. Une association ou une auto-entreprise peut très bien éditer des factures tout à fait légal au vu du droit français/européen/américain, par contre oui à la boite qui paie de s'assurer qu'elle a le droit de payer. Tu parle du FOSDEM j'imagine que c'est organisé par une association qui facture a des entreprises le sponsoring (dont au moins une grosse boite américaine de ce que je vois). Le fait qu'il faille faire des vérifications du côté de celui qui paie ne devrait pas s'interdire de le faire.
Pour être dans le cas d'une association qui facture des entreprises dont certaines américaines, je ne vois pas de problème particulier. Ils ont des protocoles qui peuvent prendre un peu de temps (les boites françaises aussi d'ailleurs), mais qui ne constitue pas une interdiction totale de le faire.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Comme openssl
Posté par Misc (site web personnel) . É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: Comme openssl
Posté par claudex . Évalué à 4.
Je ne sais pas comment les boîtes se débrouille pour les dons, mais il me semble que filer de l'argent à un pote sans rien en retour, ça peut être de l'abus de bien sociaux, il faut donc le justifier correctement.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Comme openssl
Posté par barmic 🦦 . Évalué à 2.
Tu parlais de contournement de loi et de sanction.
Bof pour discuter avec les gens qui s'en occupe ça n'a pas l'air d'être un souci.
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.
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.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Comme openssl
Posté par claudex . Évalué à 4.
Je pense que la différence entre le fosdem et un développeur lambda, c'est que dans le premier cas, tu as du sponsoring avec une grosse communauté, donc le prix se justifie. Un développeur lambda, il ne va pas avoir la même aura ou alors il faut qu'il monte une structure et ça va lui demander du boulot.
Il manque le lien de subordination qui est nécessaire pour qualifier un emploi la plupart du temps.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Comme openssl
Posté par barmic 🦦 . Évalué à 2.
Je ne suis pas organisateur du FOSDEM, la conférence que j'organise est bien plus petite et j'en ai vu la création. Le fait de faire toute les démarches semble être un acte technique. Pas amusant, plus ou moins long ou laborieux, mais ça a une influence limité sur l'acte d’achat.
Sincèrement j'ai l'impression que c'est se monter beaucoup le bourrichon pour juste répondre à la question "est-ce que c'est légal ou pas ?" et les boites qui y apportent un grand soin on l'habitude de le vérifier justement.
Ça me parait discutable. Si je clos un ticket qu'ils ont créé par exemple.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Comme openssl
Posté par Misc (site web personnel) . É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 barmic 🦦 . Évalué à 3.
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.
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. Lorsque l'on parle de tout petits streamers qui ne vivent clairement pas de ça le bénévolat peu avoir du sens (c'est un peu comme les vidéastes qui film leur potes et connaissances pour faire des courtmétrages) mais quand il s'agit de streamers qui commencent à gagner leur vie, ça devient tout de suite discutable. Surtout que la relation avec des streamers n'est vraiment pas d'égale à égale (ils sont facilement mis sur un piédestal). Il est difficile pour notre code du travail d'à la fois s'assouplir pour permettre le travail indépendant et une flexibilité que certains demandent (et je pense ici à des travailleurs qui veulent être indépendant et pas à une remise en cause du contrat de travail que l'on connaît tous) tout en protégeant les conducteur uber.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Comme openssl
Posté par Misc (site web personnel) . É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: Comme openssl
Posté par barmic 🦦 . Évalué à 2.
Non je pense à quand ils ont était sponsors d'une petite conférence à Grenoble donc facturé par un petit JUG français.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Comme openssl
Posté par Krunch (site web personnel) . Évalué à 4.
Chez nous on essai de speedruner. Je suis arrivé à 2 minute et 15 secondes cette année.
Différentes boites ont certainement différentes interprétations de ces règles. Fondamentalement, ça n'empêche pas de payer ses fournisseurs même si ça fait plus de paperasse. L'idée soulevée dans ma première réponse c'est que plein de (la plupart des ?) projets FOSS peuvent devenir des fournisseurs « comme les autres » s'ils font la paperasse nécessaire de leur côté (et ce, sans contourner FCPA ou les sanctions de l'OPAC). Plutôt que d'avoir un status spécial pour lesquelles les entreprises n'ont pas de processus prévu pour donner de l'argent (ou au mieux un budget de dons fixe et ridiculement bas comparé à ce qu'un fournisseur « normal » pourrait facturer).
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
[^] # Re: Comme openssl
Posté par barmic 🦦 . É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
[^] # Re: Comme openssl
Posté par Eh_Dis_Mwan . Évalué à 1.
je ne suis pas sûr, il y a certaines différence. Encore que pour SSL , cela pourrait en effet y ressembler
Mais il est clair que si log4j pourrait recevoir des contributions financières, ce serait cool.
Encore cette semaine, j'ai eu des clients m'annonçant sur un autre dossier "et à propos de la faille log4j, mon mgr m'a dit que le produit n'était pas touché, tu peux confirmer ?" , heureusement que la personne a eu l'audace de me poser la question.
La grande différence est que le SSL est la clé d'une connection, et il est compliqué d'oublier qu'on l'utilise , y compris sur de la db standrd (d'ailleurs, cela me fait penser à ses admins paniqué q, car incapable de faire du tomcat -> mysql ssl , ce mysql ne recevant que du localhost en inbound)
Alors que log4j, c'est un truc limite comme les sauvegardes , oui on doit logguer, mais on regarde jamais les logs, uniquement en cas de désastres
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 )
[^] # Re: Comme openssl
Posté par Misc (site web personnel) . É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 barmic 🦦 . É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
# L'opensource et maven fonctionne très bien
Posté par devnewton 🍺 (site web personnel) . Évalué à 10.
Ce que montre le drame log4shell, c'est surtout que certaines entreprises ne sont pas organisés pour mettre à jour leur logiciel et le mettre en prod rapidement.
Certains ont même des logiciels critiques pour leur business qu'elles ne savent pas reconstruire à partir des sources…
Bref du devops ni très dev ni très ops.
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: L'opensource et maven fonctionne très bien
Posté par barmic 🦦 . É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: L'opensource et maven fonctionne très bien
Posté par devnewton 🍺 (site web personnel) . Évalué à -1.
Ça m'inquiète encore plus pour logiciel d'une centrale nucléaire :-)
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: L'opensource et maven fonctionne très bien
Posté par barmic 🦦 . É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 Gil Cot ✔ (site web personnel, Mastodon) . Évalué à 1.
De ce que le Makefile est gigantesque et que personne n'a jamais documenté ce qu'il y a dedans (et donc que les nouveaux venus ne savent pas le réécrire) …par exemple ?
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
[^] # Re: L'opensource et maven fonctionne très bien
Posté par barmic 🦦 . É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 Gil Cot ✔ (site web personnel, Mastodon) . Évalué à 0.
Isaac a vu dans sa pomme de cristal ? Ou juste une possibilité (avec une forte probabilité non mentionnée) dystopique ?
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
[^] # Re: L'opensource et maven fonctionne très bien
Posté par Benoît Sibaud (site web personnel) . Évalué à 8.
Si l'attaquant contrôle une machine du réseau local, c'est dangereux aussi (pour en infecter plein d'autres via la faille log4j). Mais bon il y avait déjà un gros problème au départ.
[^] # Re: L'opensource et maven fonctionne très bien
Posté par barmic 🦦 . É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 Eh_Dis_Mwan . Évalué à 3.
Entendu dans une start up / licorne Française "Tester, c'est pas très agile"
[^] # Re: L'opensource et maven fonctionne très bien
Posté par Gil Cot ✔ (site web personnel, Mastodon) . Évalué à 7.
C'est surtout pas trop compatible avec le fameux time-to-market qui se réduit de jour en jour.
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
[^] # Re: L'opensource et maven fonctionne très bien
Posté par Eh_Dis_Mwan . Évalué à 2.
la faute à qui ?
[^] # Re: L'opensource et maven fonctionne très bien
Posté par Michaël (site web personnel) . Évalué à 5. Dernière modification le 25 décembre 2021 à 21:12.
C'est effrayant de lire ça!
On peut faire du continuous delivery et tester automatiquement. 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). Dans mon équipe (une petite vingtaine) on déployait peut-être des dizaines de fois par jour. Tout toujours testé et un time to market de quelques jours à peine (il faut quand-même concevoir et programmer.)
Si des gens ont besoin de cours particuliers et d'assistance pour monter ce genre d'infra, je suis joignable, encore environ 2j libres par semaine. :-)
[^] # Re: L'opensource et maven fonctionne très bien
Posté par ff9097 . Évalué à 3.
CI c'est le minimum en effet. Après le delivery a chaque push je dirais que ça dépends.
[^] # Re: L'opensource et maven fonctionne très bien
Posté par Michaël (site web personnel) . Évalué à 6.
Même si il y a apparemment de bonnes raisons de ne pas forcément vouloir déployer à chaque push, l'argument les plus important pour cette pratique, à mes yeux, suit le plan suivant:
Il faut toujours être en capacité de déployer car on peut avoir besoin de corriger un problème grave.
Plus rarement on déploie, moins on a confiance dans sa procédure de déploiement et la peur du déploiement commence à s'installer dans l'équipe.
Plus rarement on déploie, moins les développeurs attachent de l'importance à la procédure de déploiement, car celle-ci prend moins de place dans leur travail et qu'ils ont normalement bien assez de problèmes pour occuper leur temps.
Plus rarement on déploie, plus la procédure de déploiement diverge de l'application, et plus les effets sont imprévisibles au prochain déploiement… ce qui accentue la peur du déploiement.
Plus rarement on déploie, plus la procédure de déploiement introduit une incertitude difficile à évaluer sur la livraison. On croit avoir fini, à entendre les développeurs, mais en réalité il reste beaucoup de travail à faire parcequ'on a privilégié les “features” au déploiement sans tenir compte du fait que non déployée une “feature” est un investissement sans gain.
On peut étoffer cette liste à l'envi. Cependant même si on déploie tout tout de suite, on a à sa disposition plein de techniques qui permettent de faire cela sans pour autant introduire des incompatibilités ou dégrader le ressenti et le travail des utilisateurs.
Pour des arguments d'une toute autre nature, les auteurs du petit livre “Accelerate” expliquent en se basant sur leur large observation empirique que les entreprises technologiques qui ont les meilleures résultats sont celles qui optimisent quatre métriques particulières (“4 key metrics”) et que l'adoption de la livraison continue est un changement organisationnel qui par essence optimise ces quatre métriques.
[^] # Re: L'opensource et maven fonctionne très bien
Posté par barmic 🦦 . É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
[^] # Re: L'opensource et maven fonctionne très bien
Posté par Michaël (site web personnel) . Évalué à 2.
Non je suis allé prendre mon poste d'agrégé au lycée en septembre après avoir épuisé tous les congés possibles mais je ne pense pas y rester très longtemps … (c'est une autre discussion cependant!)
Oui c'est assez grand mais c'est transitoire: il y a une période de transfert de compétence avec 4-5 nouveaux collègues qui ont commencé dans les tous derniers mois puis un partage de l'équipe en deux. C'est aussi des équipes pluridisciplinaires, quasi des mini-entreprises autonomes dont on parle. Sur tout le projet il y a quelques centaines de personnes qui travaillent, avec deux très gros tiers de développeurs, répartis sur une dizaine de sites, dans quatre pays! La plupart sont dans de groupes entre 8 et 20, mais quand ça monte au dessus de 13 c'est souvent pour préparer une “scission.”
Ç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é). Ensuite on avait le confort énorme de travailler en “back office” ce qui fait qu'on a une “feedback loop” très courte, pas comme si on devait faire des enquêtes de satisfaction de l'utilisateur avec une société de communication par exemple, puisqu'on est à quelques mètres des utilisateurs.
Il faut aussi se mettre d'accord sur la façon de mesurer le “time to market.” Dans les contextes où j'ai exercé le bon signal de fin semble être “la première fois que la fonction entre en production” même si après il faut remettre son ouvrage sur le métier, c'est normal c'est la nature du logiciel de ne jamais être terminé. Pour une agence de développement qui dit à ses clients “on aura fini dans trois mois” je suppose qu'un point de vue légèrement différent s'impose. Il y a certainement plein d'autres environnements qui vont tirer vers d'autres équilibres.
C'est effectivement ce qui nous demandait le plus de travail. Notre démarche était pre 1. d'avoir un environnement “stage” pour les tests et 2. d'avoir un test d'intégration dès les premières itérations du développement, même s'il s'agit de faire un simple curl sur le “health dashboard” de notre application tier3.
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.
Pour le 2, même si les premiers tests ne semblent pas spectaculaires ça aide d'avoir un véhicule pour ajouter les nouveaux tests d'intégration au fur et à mesure que l'application s'étoffe. Selon l'avancement du projet et les besoins de l'équipe les tests d'intégration peuvent être sophistiqués ou très basiques, par exemple se concentrer sur une ou deux fonctions cruciales dans le cas favorable (sans trop regarder les conditions d'erreur), et tout de même avoir leur utilité, surtout du côté infra (connectivité réseau, droits d'accès, etc.)
[^] # Re: L'opensource et maven fonctionne très bien
Posté par barmic 🦦 . É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: L'opensource et maven fonctionne très bien
Posté par Philippe F (site web personnel) . Évalué à 5.
Dans mon industrie (la carte à puce), faire tourner l'ensemble des tests d'une carte prend environ 3 jours, avec environ 4 lecteurs de carte à puce en parallèle (parfois beaucoup plus).
Donc le "je teste tout à chaque push", ça me parait difficile.
[^] # Re: L'opensource et maven fonctionne très bien
Posté par Michaël (site web personnel) . Évalué à 2.
Oui dans ce genre de situation cela paraît difficile. Est-ce que tu as envie d'expliquer les particularités qui font que les tests prennent si longtemps? Ce que tu écris c'est le logiciel de la puce?
Est-ce qu'une approche qui consisterait à avoir un sous-ensemble de tests qui tourneraient le plus souvent possible (plusieurs fois par jour, quitte à avoir des “trains” qui partent à heure fixe par exemple) apporterait quelque chose? Pas grand chose? Serait contre-productive? Cela rend curieux :-)
[^] # Re: L'opensource et maven fonctionne très bien
Posté par Renault (site web personnel) . Évalué à 6.
C'est surtout que la pertinence de déployer en permanence ne fait pas beaucoup de sens suivant le milieu.
Par exemple si tu codes un site web ou une plateforme interne d'une entreprise, déployer signifie mettre à jour un serveur voire plusieurs serveurs éventuellement sans contraintes e ressources tout en étant transparents pour l'utilisateur.
Si à chaque commit il y a une mise à jour d'une application Android ou iOS, cela veut dire que sur la semaine l'utilisateur aura plein de MaJ automatique. C'est de la data (pas infinie) qui est consommée et des notifications régulières ce qui emmerde l'utilisateur.
Dans mon travail dans l'embarqué, certains appareils sont connectés derrière des routeurs 4G où chaque Mo est compté (et une MaJ c'est 30 Mio), et si l'interruption de service tombe au mauvais moment c'est 1-2 minutes de pertes de données précieuses pour le client.
Donc déployer à chaque commit, hors de questions. Cela serait trop cher et contraignant pour le client.
[^] # Re: L'opensource et maven fonctionne très bien
Posté par Psychofox (Mastodon) . Évalué à 6.
Tout dépend de ce qu'on appelle déployer.
Dans le cas d'une appli desktop/mobile on parle en général de distribution asynchrone. Ce sont les appsreils qui se mettent à jour et font des requêtes aux serveurs. Du coup déployer signifie mettre à disposition dans les repos / app store. Pour certaines applis on peut avoir un repôt/package dédié aux versions beta et nightly builds qui permettent aux plus aventureux de tester sans envoyer la sauce à tout le monde.
Du reste autant pour le web/serveur que pour le desktop/mobile le déploiement automatisé s'accompagne en général de méthode de type canary release. On ne va pas mettre à disposition à tout le monde à un instant t la dernière version mais on le fait graduellement. Dans le cas des services via du load balancing, pour le cas d'applis desktop/mobiles on ne va mettre à dispo la dernière version dans un premier temps qu'à une population précise.
[^] # Re: L'opensource et maven fonctionne très bien
Posté par Philippe F (site web personnel) . Évalué à 7.
Je fais la remarque pour inviter à prendre du recul sur le déploiement continu.
Les particularités qui font que ça prend si longtemps, c'est que seul un test sur la carte finale est vraiment fiable pour une livraison. Et une carte à puce, c'est lent, et communiquer avec une carte à puce, c'est lent aussi.
On fait bien sur des tests sur des simulateurs beaucoup plus rapides, mais qui ne garantissent pas l'absence d'erreurs. Seule la carte finale peut te donner confiance.
Si on compte toutes nos bases de test, on est largement au dessus des 100 000 tests sur les cartes SIM, et autour des 100 000 sur des objets plus simples comme les cartes bancaires.
Alors pourquoi c'est aussi compliqué une carte à puce, cela reste en partie un mystère pour moi. On a globalement de la crypto, de la communication, une VM Javacard, des systèmes de distributions de clés et d'applications Javacard (GlobalPlatform). Les gars du GSM ont en plus une pile TCP si je me souviens bien et un client http et un client dns.
Parmi les tests les plus longs, il y a la coupure de courant/champs en plein milieu d'une opération critique. Tu prends une opérations critique et tu répètes ton test un coupant le courant au bout de 0.001 s puis 0.002s etc et tu vérifies que la carte n'est pas corrompue après chaque test.
En pratique, on fait tourner une intégration continue avec les batteries pas trop longue (moins de 10h) toutes les nuits, et le reste le weekend.
Bien sûr, on peut toujours viser un sous-ensemble de ces tests à tourner sur chaque commit, mais extraire et maintenir ce sous-ensemble demande un savoir-faire et une expertise sur nos bases de tests qui n'est pas forcément disponible. C'est surtout l'aspect maintenance de ce type de suite qui est délicat.
Donc on fait comme on peut, en allant vers plus d'intégration continue qu'avant.
Ah oui, j'oubliais un détail comique: la flash, c'est entre 100 000 et 500 000 écritures en gros. Sur des bases de test un peu intensive (et écrites comme des cochons), on grille l'endurance de la flash en trois jours sur une carte. Ce qui se traduit quand tout va bien par un gros fail, mais plus généralement par des échecs aléatoires dans la suite de test, qu'il faut trier d'échecs légitimes générés par du code nouveau.
Bref, ca peut être la mouise. Cela dit, avec toutes ces contraintes, je trouve que ma boite s'en tire bien. On s'appuie sur des bons outils internes pour gérer la problématique globale et on va vraiment sur plus d'intégration continue et de reproductibilité des problèmes. Peut-être même qu'un outil open source verra le jour sur un sujet connexe lié à tout ça.
[^] # Re: L'opensource et maven fonctionne très bien
Posté par barmic 🦦 . Évalué à 3.
Vraiment sans chercher à te dire comment tu dois travailler ne l'ayant moi-même jamais mis en place, une technique pour ça est de gérer cette liste dynamiquement en fonction des statistiques de réussite et d'échec.
Ça part de 2 hypothèses :
L'idée c'est donc d'alimenter un algo qui va lancer une base de tests qui plante plus souvent que les autres et qui limite la redondance.
Ça ne dit pas qu'on détruit tous les autres juste qu'on les exécute moins souvent.
Perso j'adore l'idée, même si je n'ai jamais eu l'occasion de le mettre en place.
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 Michaël (site web personnel) . Évalué à 2.
Merci, c'est détaillé et très intéressant. Est-ce qu'une solution hybride, avec de la “petite intégration continue” qui utilise le simulateur après chaque push et une “grande intégration continue” sur une base périodique qui se fait sur le matériel, pourrait te sembler pertinente?
# Ca vaut ce que ça vaut mais...
Posté par Guillaume Smet (site web personnel) . Évalué à 10.
Ce qui est plutôt beaucoup pour ce genre de bibliothèques très ciblées. Des tonnes de bibliothèques beaucoup plus grosses sont maintenues par quelques personnes sur leur temps libre. Le développeur principal de Jackson (bibliothèque JSON et bien plus quasi omniprésente dans le monde Java) par exemple travaille dessus sur son temps libre. C'est le cas de bien d'autres projets Open Source.
Et même quand ce n'est pas sur le temps libre, il y a souvent très peu de contributeurs et beaucoup de choses à faire.
Ensuite, peu de développeurs sont sensibilisés à la sécurité. Et même dans ce cas, quand tu vois arriver une pull request avec un truc qui peut être pratique pour les gens, tu ne prends pas toujours le recul nécessaire pour te rendre compte des conséquences. Bien souvent les problèmes de sécurité sont amenés comme ça : une fonctionnalité qui a l'air pratique alors pourquoi pas… et boum deux ans après quelqu'un se rend compte qu'il y a une faille évidente.
Ben non, justement. Maven a tout un tas de mécanismes pour corriger ce problème très simplement.
Beaucoup d'entreprises ont des proxies Maven que tous les builds utilisent pour récupérer les dépendances : elles peuvent bannir les anciennes versions directement sur le proxy.
Je pense aussi que beaucoup d'entreprises ont un pom parent et il est facile via une directive dependencyManagement de forcer la version de log4j - alors ce ne sera pas exactement forcé car si un projet la déclare explicitement, la version explicite prend le pas, mais ça enlève au moins toute la partie "une vieille dépendance dépend d'une vieille version de ce truc". Mais pour ça, tu peux utiliser l'enforcer plugin pour bannir des dépendances.
Il y a aussi tout un tas de gens qui ont développé des agents pour réécrire le code à la volée.
Log4j 2 est loin d'être la pire dépendance pour ce genre de problèmes car l'API est assez récente et assez stable donc la mise à jour très facile. Ca aurait pu être bien pire (genre nécessiter des changements d'API dans tous les sens pour que des vieux trucs non maintenus puissent encore fonctionner).
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 ?
Et j'attends avec une impatience toute relative la première GitHub Action non officielle utilisée largement qui sera reprise par un mainteneur peu scrupuleux et qui injectera du code un peu partout dans tous les repositories qui l'utilisent. Ca va être extrêmement sympathique.
[^] # Re: Ca vaut ce que ça vaut mais...
Posté par barmic 🦦 . É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: Ca vaut ce que ça vaut mais...
Posté par Guillaume Smet (site web personnel) . Évalué à 2.
C'est l'arbre qui cache la forêt franchement. C'est bien, c'est sûr mais ciblé sur quelques composants.
Les composants qui terminent dans des tonnes d'applications, il y en a des milliers. Et beaucoup d'entre eux sont maintenus par des toutes petites équipes en mode arrache. Et il en suffit d'un.
Log4j 2 est un exemple intéressant car c'est un projet Apache, qui a des règles plutôt strictes de revue, de votes, d'intégration dans les équipes… Donc globalement un projet sain et plutôt sécurisant. Et la faille est due à de la maladresse, pas de la malveillance.
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).
Note que je n'ai pas de solution miracle. Je pointe juste un problème systémique qui va avec la réutilisation massive de composants et aussi leurs multiplications. Je pense qu'au début de l'Open Source, c'était plus compliqué de mettre en place ce genre de vecteur parce que rien que mettre en place ton infra de développement, release, te faire connaître, ça demandait du temps et un sacré effort. C'est beaucoup plus facile maintenant. Ca a de très bons côtés mais aussi des composantes qui demandent de la prudence.
Les GitHub Actions sont un excellent exemple : GitHub fournit très très peu de GitHub Actions standards et facilite la mise en place d'un écosystème d'actions. Et ça fleurit dans tous les sens avec plein de gens qui réutilisent des actions déjà faites sans les regarder car très pratique. Au niveau de ton repository, tu pointes vers un repo externe généralement vers une version glissante (donc le code de l'action peut évoluer dans le temps) et tu utilises cette action pour builder/releaser. Il est super facile d'utiliser la dite action pour injecter du code, par exemple dans un workflow de release pour que ce soit discret (tu verrais facilement une manipulation de la branche main mais pour un tag c'est hyper discret).
L'Open Source repose beaucoup sur le modèle scientifiquement appelé "modèle Bisounours" où le monde entier est gentil et essaie de faire avancer tout le monde. Jusqu'à présent, ça marche plutôt bien. Mais c'est super super fragile si on commence à introduire des gens mal intentionnés qui ont du temps dans le bazar. Espérons qu'ils restent occupés à miner des bitcoins :)
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.
[^] # Re: Ca vaut ce que ça vaut mais...
Posté par Misc (site web personnel) . É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: Ca vaut ce que ça vaut mais...
Posté par barmic 🦦 . É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 Guillaume Smet (site web personnel) . Évalué à 2.
Encore une fois, j'ai bien précisé que je n'avais pas spécialement de solution au problème. Je n'appelle rien de mes voeux, je pointe juste un souci qui existe et que les gens minimisent, volontairement ou non.
Exemple réel vu dans la vraie vie et contre lequel j'essaie de me battre : utiliser une GitHub Action d'un repo tierce pour mettre en place la configuration GPG en lui passant la clé et la passphrase. Et ce n'est pas un exemple inventé.
Autre exemple : des applications tierces qui facilitent le développement à qui tu donnes le droit de commit sur ton repository.
Je n'appelle pas à la construction d'une cathédrale, j'appelle juste les gens à un peu de prudence et à se rendre compte de ce qu'il se passe. Certaines pratiques sont dangereuses et c'est plutôt une bonne idée de s'en rendre compte. Après, chacun décidera s'il veut ajuster son comportement ou pas. Parfois, c'est une bonne idée de se priver d'un peu de confort pour éviter de se prendre un mur plus tard.
Le jour où quelqu'un ciblera un framework largement utilisé en injectant du code pour envoyer quelque part les comptes et les mots de passe, j'ai du mal à voir en quoi ta CI et des bugs bounties vont aider. On s'en rendra compte à un moment mais bonjour les dégâts.
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.
[^] # Re: Ca vaut ce que ça vaut mais...
Posté par barmic 🦦 . É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 Guillaume Smet (site web personnel) . Évalué à 2.
Euh non, je ne suis pas dans l'émotion du moment, je suis passé plutôt entre les gouttes pour Log4Shell : on utilise JBoss Logging donc ça ne m'a pas vraiment impacté. On a fait des releases parce qu'on utilise l'API pour la brancher dans JBoss Logging (et donc pas l'implémentation où est la faille) et qu'on ne voulait pas se faire flagger en faux positif par les outils de scan pas trop finauds.
Et mon raisonnement n'est pas lié à cela, ça fait 2 ans que je vois les dérives que je souligne. Comme je le disais précédemment, les projets Apache ne sont pas vraiment impactés par ce problème particulier. Ils ont une gouvernance et une infra assez sécurisées globalement.
Prends un peu de recul par rapport aux exemples que je donnais sur GitHub Actions. Ils sont réels et symptomatiques de comment les choses sont faites de nos jours. Comme je le disais, ça simplifie la vie. Après, dans beaucoup de cas, les gens ne se rendent pas compte qu'ils donnent le droit de commit à du code tierce dans leurs repositories. Et qu'à partir de ce moment là, il est super facile d'injecter du code et que la probabilité de s'en rendre compte si c'est bien fait avant que ça impacte des utilisateurs est proche de 0.
Etre conscient du problème, c'est déjà un pas dans la bonne direction. Et ça ne veut pas dire qu'il faut jeter le logiciel libre avec l'eau du bain (sinon je me retrouverais au chômage et ça m'arrangerait moyen). 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.
Après, des boulettes, il y en aura toujours et tout le monde en fera. Mais ce n'est pas de cela que je parle.
Je ne pense pas que ce soit une bonne raison de ne pas se poser de questions sur les pratiques d'aujourd'hui et sur comment faire en sorte d'améliorer la résilience de l'écosystème en général. Certaines pratiques d'aujourd'hui sont nouvelles et extrêmement dangereuses. Perso, je préfère en être conscient et faire attention sur mes projets.
Après, chacun fait bien comme il veut :).
[^] # Re: Ca vaut ce que ça vaut mais...
Posté par barmic 🦦 . É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 Guillaume Smet (site web personnel) . Évalué à 3.
C'est fou comme on a du mal à avoir une discussion posée ici. Tu sais, on peut discuter sans chercher la petite bête dans ce que l'autre écrit et lui donner le bénéfice du doute quant à sa cohérence. On peut aussi ne pas être d'accord et avoir tous les deux raisons car des enjeux différents.
Pour expliquer ce que je disais :
Cette partie-là désigne un absolu. Si tu veux être sûr de ton composant, il faut que toute la chaîne soit sure. C'est infaisable dans les faits d'avoir la capacité à vérifier chaque maillon de la chaîne à chaque instant. Mais il est important de le savoir et d'en être conscient.
Du coup, il est de la responsabilité de chaque maillon à son échelle de faire du mieux qu'il peut et d'éviter les comportements les plus dangereux. Parce que tout le reste de la chaîne va en payer le prix.
D'où le :
Et par rapport à ce que tu dis toi :
Il y a une petite nuance et elle est importante, je l'avais précisé plus haut : tout est plus facile de nos jours, ce qui rend les comportements dangereux moins visibles. Entre utiliser un plugin Maven qui a dû être déployé sur Maven Central (et donc quand même avoir quelques petits checks au cours de la démarche, même si pas idéal) et juste pointer vers un repo GitHub arbitraire, il y a un monde. Tu pourras me dire qu'on pouvait ajouter un repo Maven externe. Sûr mais c'était moins fluide et j'ai l'impression que plus de gens se rendaient compte qu'il fallait faire attention dans ce cas. Ca ne m'empêchait pas de le faire parfois mais je mesurais quand même ce que ça m'apportait par rapport au risque.
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. Et je m'en rends bien compte car j'ai le plus grand mal du monde à convaincre des ingénieurs par ailleurs brillants que c'est un souci d'envoyer sa passphrase à du code externe (et mouvant vu que pointant sur un tag mouvant genre
v2pour suivre toutes les évolutions du dit repo). Et oui, le maven-gpg-plugin, on lui envoie aussi la passphrase. Mais c'est du Apache et leur mode de fonctionnement est très sécurisant vis à vis de la malveillance organisée. Donc c'est un risque que je suis prêt à accepter.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).
Je comprends très bien ta position mais je pense que les choses sont beaucoup plus nuancées et que généraliser des pratiques dangereuses (et inutiles dans certains cas, cf mon exemple) en se disant qu'il y a bien quelqu'un qui trouvera la faille un jour, ça ne me semble pas la meilleure manière de faire les choses et qu'avoir un comportement plus responsable et conscient des dangers à chaque étage est souhaitable. Ce qui n'empêche pas de prendre des risques quand ça en vaut la chandelle mais au moins on en est conscient et ça change tout.
Ca n'empêchera pas les boulettes et c'est la vie. Mais franchement, évitons les risques inutiles.
[^] # Re: Ca vaut ce que ça vaut mais...
Posté par barmic 🦦 . É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
# La vraie remise en question
Posté par Colin Pitrat (site web personnel) . Évalué à 8.
Ce que j'aimerais vraiment voir remis en question c'est la course à la fonctionnalité, le fait de vouloir qu'un logiciel coche un maximum de cases. Vive les outils/bibliothèques simples et ciblées. Ou au moins modulaires avec les fonctionnalités avancées (voir kikoo-lol) désactivées par défaut. Cela permet de limiter la surface d'attaque et d'économiser les ressources.
Parce que dans log4j, combien d'utilisateurs en avaient vraiment besoin du formatage qui contacte ldap automatiquement. Et l'injection de classe, aussi utilisée dans l'attaque, pourrait être désactivée par défaut et nécessiter d'être activé depuis le programme appelant si nécessaire.
[^] # Re: La vraie remise en question
Posté par Eh_Dis_Mwan . Évalué à 5.
Cela répond souvent à des demandes clients. Si tu savais les request for enhancement que j'ai reçu dernièrement. Tout pour judstement élargir le périmètre d'attaque. Par contre , les demandes d'update de modules sont bcp plus rare.
On reçoit plus "on aimerait pouvoir faire …."
Que
"Votre lib ne supporte pas tls v1.3…"
[^] # Re: La vraie remise en question
Posté par Misc (site web personnel) . É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: La vraie remise en question
Posté par barmic 🦦 . É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: La vraie remise en question
Posté par Eh_Dis_Mwan . Évalué à 2.
Attention quand même, log4j 1 semble quand même moins troué pour le moment.
Mais oui, tout ça me rapelle le bon vieux temps où le prof sysadmin d'iut nous disait
"plus de sécurité, moins de confort. Plus de confort , moins de sécurité" .
Aujourd'hui, c'est "putain fait chier, ma banque me demande de confirmer mon achat sur mon smartphone"
[^] # Re: La vraie remise en question
Posté par _kaos_ . Évalué à 4. Dernière modification le 25 décembre 2021 à 11:16.
C'est un peu normal, il y a moins de fonctionnalités. D'un autre côté, c'est aussi en EOL depuis 2015… donc moins troué, c'est loin d'être certain dans l'absolu. Moins impacté par cette CVE, oui.
Mais ça ne marche plus avec Java 9 par exemple, ce qui apporte d'autres légers soucis indépendamment de ceux directement imputables à une librairie en EOL :)
Matricule 23415
[^] # Re: La vraie remise en question
Posté par Misc (site web personnel) . É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 _kaos_ . Évalué à 3. Dernière modification le 25 décembre 2021 à 17:39.
La banque elle-même est généralement assurée, et il arrive que l'assureur assurant soit également assuré. :)
Ça dépend des risques et de ce qu'on veut couvrir…
Matricule 23415
[^] # Re: La vraie remise en question
Posté par Laurent Pointecouteau (site web personnel, Mastodon) . Évalué à 1.
Alors, j'ai eu une discussion avec le monsieur qui s'occupe de ça dans notre boîte, et il m'a assuré que bien au contraire, c'était toujours recommandé par l'ANSSI, que le seul problème avec ce système c'était que les gens mettaient des mots de passe qui ressemblaient trop aux précédents, et que chez nous, on allait implémenter un truc pour vérifier que les nouveaux mots de passe sont suffisamment différents. Donc, à présent, nous allons avoir 2 mots de passe à modifier complètement tous les 2 mois.
[^] # Re: La vraie remise en question
Posté par Jérôme FIX (site web personnel) . Évalué à 3.
En fait la recommandation est de ne pas changer les mots de passe pour les comptes peu sensibles (cf 4.4 Délai d'expiration des mots de passe)
https://www.ssi.gouv.fr/uploads/2021/10/anssi-guide-authentification_multifacteur_et_mots_de_passe.pdf
Mais bien entendu il faut que les mots de passe soient robustes.
[^] # Re: La vraie remise en question
Posté par Laurent Pointecouteau (site web personnel, Mastodon) . Évalué à 2.
Ouais, c'est ce que j'avais compris en le lisant de mon côté. Bon, dans mon cas il s'agit du mot de passe de notre trousseau de clés (plus le mot de passe de je ne sais plus quelle appli qui évidemment est incompatible avec ledit trousseau de clés), donc extrêmement sensible pour le coup.
[^] # Re: La vraie remise en question
Posté par devnewton 🍺 (site web personnel) . Évalué à 3.
Les bonnes pratiques évoluent, si je me souviens bien :
Si on lance une application demain, je conseillerais de logger bêtement dans stdout en JSON et de laisser un ELK s'occuper de parser et de générer des tableaux de bord.
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: La vraie remise en question
Posté par barmic 🦦 . É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: La vraie remise en question
Posté par devnewton 🍺 (site web personnel) . Évalué à 1.
Ne lis jamais un rapport Sonar, tu vas te faire très peur :-)
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: La vraie remise en question
Posté par barmic 🦦 . É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: La vraie remise en question
Posté par Eh_Dis_Mwan . Évalué à 1.
Jee ne sais pas les recommandations hw exacte pour ELK mais d'expérience, j'ai jamais vu un truc aussi lourd, peu "écologique", l'outil idéal pour overhead les serveurs ( et sans la maintenance sortie de nulle part avec les apis )
[^] # Re: La vraie remise en question
Posté par Misc (site web personnel) . É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 ff9097 . Évalué à 3.
Je vois pas le rapport entre LDAP et les logs
[^] # Re: La vraie remise en question
Posté par Misc (site web personnel) . É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).
# audit
Posté par Psychofox (Mastodon) . Évalué à 6.
Combien d'entre vous sont developpeurs et combien d'entre vous réalisez directement ou via une tierce partie des audits sécurité de vos logiciels et en particulier de toutes les bibliothèques que vous utilisez pour vos programmes?
Il et là le problème. Qu'il y ait 1 ou 2 developpeurs à temps partiels d'une librairie utilisé par des milliers d'entreprises et indépendants c'est une chose. Mais que tous incorporent des briques logiciellesles yeux fermés sans se poser de question pour leurs besoins métiers, c'est une honte et une abbération.
[^] # Re: audit
Posté par vitanix . Évalué à 1.
Dans ma boite on fait, il y a des audit de sécurité systématiquement avant mise en prod. nous on utilise spring boot avec logback, donc on n'a pas été impacté par ce trou de sécurité.
# Isolation des accès réseaux
Posté par vitanix . Évalué à 1. Dernière modification le 27 décembre 2021 à 16:06.
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. Par exemple si je pouvais indiquer que cette application ne peut se connecter qu'à l'url
http://masecondeapli/api/*, ce trou de sécurité ne ne poserait pas. Pour le filesystem, si l'appli n'avait accès en lecture/écriture qu'a une sous partie du FS réel, cela permettrait de limiter fortement les attaque de ransomeware.Le top, ce serait une vrai gestion des applications comme dans android, mais avec une gestion plus fine des droits, pour indiquer que l'application n'a accès qu'aux url x, y et x et aux répertoires a en lecture, b en écriture et c en lecture/écriture.
[^] # Re: Isolation des accès réseaux
Posté par Krunch (site web personnel) . Évalué à 1.
En gros il faut tuer Unix quoi.
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
[^] # Re: Isolation des accès réseaux
Posté par barmic 🦦 . É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: Isolation des accès réseaux
Posté par Krunch (site web personnel) . Évalué à 4.
Unix dans le sens de sur-ensemble d'une approximation de POSIX. Ça exclut Plan 9 mais inclut GNU.
Effectivement, il y a plein « d'évolutions » (des gros hacks) par dessus Unix et ses dérivés qui prétendent améliorer la sécurité. Mais architecturalement, comparé à un système qui est conçu pour la sécurité à la base, ça reste comme même bien de la merde d'un point de vue sécurité (y compris « utilisabilité » de l'aspect sécurité). Tu peux pas vraiment te débarrasser de root, suid, sh et autres pièges de sécurité et continuer de prétendre être un Unix.
Worse is Better.
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
[^] # Re: Isolation des accès réseaux
Posté par Misc (site web personnel) . É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 Gil Cot ✔ (site web personnel, Mastodon) . Évalué à 3.
Où ça sur https://www.freebsd.org/ ?
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
[^] # Re: Isolation des accès réseaux
Posté par Misc (site web personnel) . É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: Isolation des accès réseaux
Posté par Gil Cot ✔ (site web personnel, Mastodon) . Évalué à 2.
Pas de souci (je manque un peu de sommeil aussi) c'était surtout pour avoir la référence
:-)Après, comme tu le fais remarquer, UNIX (que j'écris toujours en majuscules pour ma part) est une marque déposée (initialement de AT&T mais maintenant la propriété de l'Open Group…) Les systèmes Unix-like (parfois abrégé Unix tout court, et que pour ma part j'écris comme un nom/titre –début en majuscule et le reste en minuscules) ou, en français de type Unix, ou plus généralement de la « famille Unix » ; reprennent les principes (architecturaux, fonctionnels et organisationnels) ainsi que le mode de fonctionnement légué par le Bell Labs. Cela se résume actuellement à l'adhérence aux standards/normes POSIX et sUs.
Les BSD ne sont pas plus ou moins Unix-like que les GNU/Linux ou les GNU/Hurd (par contre, effectivement, le fonctionnement par défaut fait parfois entorse à POSIX à moins de poser des variables d'environnement
POSIXLY_CORRECTet similaires…)“It is seldom that liberty of any kind is lost all at once.” ― David Hume
[^] # Re: Isolation des accès réseaux
Posté par Gil Cot ✔ (site web personnel, Mastodon) . Évalué à 2.
Comme déjà répondu, Plan9 n'est pas un Unix : ne respecte pas vraiment, à dessein, la single UNIX specification.
GNU/Linux est bien un Unix-like dans l'esprit… Mais GNU a toujours indiqué dès le début dans son acronyme ne pas vouloir faire un clone bien que partant de ce système comme référence. Bien que ayant toujours eu à cœur de respecter POSIX dans ses implémentations, ils s'offrent le luxe de ne pas s'y conformer par défaut (voir
POSIXLY_CORRECTpar exemple.)“It is seldom that liberty of any kind is lost all at once.” ― David Hume
[^] # Re: Isolation des accès réseaux
Posté par Misc (site web personnel) . É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: Isolation des accès réseaux
Posté par barmic 🦦 . Évalué à 3.
Merci je connaissais pas.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Isolation des accès réseaux
Posté par claudex . Évalué à 5.
Ou carrément filtrer par domaine en sortie avec sidecar proxy comme Istio (ou d'autres) le permet.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Isolation des accès réseaux
Posté par barmic 🦦 . Évalué à 3.
Hum je connais pas bien istio, il va rediriger les requètes vers lui via la résolution de nom ? Si oui il faut une network policies tout de même pour empêcher de le by pass par des requêtes direct sur les API c'est ça ?
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Isolation des accès réseaux
Posté par claudex . Évalué à 5.
Non, istio ne fonctionnerait pas avec les NetworkPolicy vu que c'est un sidecar et que les NetworkPolicy ne fonctionne que par pod et pas par container. Il va utiliser un init container avec les capabilities nécessaire pour forcer la redirection du trafic du container vers le sidecar via des règles iptables (ou le faire via un CNI).
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Isolation des accès réseaux
Posté par barmic 🦦 . Évalué à 3.
D'acc merci pour l'explication
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Isolation des accès réseaux
Posté par devnewton 🍺 (site web personnel) . Évalué à 4.
Ce que tu veux est déjà possible.
Normalement une bonne DSI aura :
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.