De ce que j’ai compris (à prendre avec des pincettes, donc), les kernels panic étaient avec l’implémentation eBPF _mais_, il s’agissait d’un backport d’eBPF par RedHat pour le vieux noyau utilisé du fait de leur politique LTS (la version majeure du noyau ne change pas mais il y a tellement de backports que ce n’est plus comparable à un noyau Linux vanilla).
Bref, le module eBPF de CrowdStrike aurait révélé un bug dans le backport d’eBPF, rapidement corrigé par RedHat.
D'autre part le panic ne venait pas directement de l'exécution du programme ebpf, mais de sa vérification au préalable, un programme ebpf be pouvant pas de lui-même provoquer un kernel panic.
Donc le bug était côté linux/redhat.
Pour moi ça ne remet pas en cause la meilleure pertinence de l'approche ebpf/sandboxée, a l'opposé de ce que fait windows aujourd'hui. Évidemment il faut que le socle (côté linux/kernel) soit en béton armé, mais ça sécurise énormément les choses en cas de souci côté éditeur tiers.
(D'ailleurs ebpf pour windows existe, peut-être qu'il manque de maturité mais ça peut être la solution à l'avenir)
Parce que la partie montée peut être vérifiée/signée et tout c qu'on veut, les fichiers de paramétrage ne le sont pas.
Ce n'est pas "plus safe" que Windows: Windows vérifie des signatures - Linux vérifie au kernel et Windows externalise, c'est tout.
Non non, je maintiens, en théorie un programme eBPF ne peut pas kernel panic. Là, il l'a fait à cause d'un bug (désormais fixé) dans le vérificateur. [Edit: en réalité c'est le vérificateur qui a crashé à cause du programme, le programme lui-même n'ayant même pas été exécuté, si je suis bien] . Le programme eBPF peut éventuellement crasher, être buggé, etc. mais ça ne devrait pas affecter le noyau, ou du moins pas jusqu'au crash.
The worst thing an eBPF program can do is to merely consume more resources than is desirable, such as CPU cycles and memory. eBPF cannot prevent developers writing poor code -- wasteful code -- but it will prevent serious issues that cause a system to crash.
Le
21/07/2024 à
23h
18
Le hook noyau / eBPF est sensé être sûr (code exécuté dans une sandbox, et passé par un vérificateur), et d'ailleurs crowdstrike sur linux semble fonctionner ainsi. Donc a priori, plus safe que sous windows... sauf que même comme ça, ils parviennent à déclencher un kernel panic (en théorie ça devrait pas)
cf red hat qui a eu un problème similaire en juin https://access.redhat.com/solutions/7068083 - un patch côté kernel a corrigé le vérificateur eBPF pour ça.
La question qui tue maintenant, c'est : est-ce que ce désastre sera suffisant pour que cette entreprise à $74Mds se dise que ce serait peut-être bien de (mieux) tester ses màj? Vu la com assez laconique, on peut se poser la question.
Publiquement accessible ne signifie qu'on peut légalement en faire ce qu'on veut.
C'est très bien d'avoir une hygiène numérique, ça n'excuse pas pour autant la réutilisation sans consentement ... a priori la question du droit d'auteur sur le matériel d'entraînement n'est pas tranchée (?)
J'ai pas lu l'étude elle-même mais je suppose que l'argument de la courbe d'apprentissage concerne les collègues qu'on n'a pas réussi à débaucher de twitter
"On ne fera XYZ que dans les limites imposées par la loi"
Ok mais, par définition, ça aurait été illégal sinon. Donc je vois pas en quoi c'est rassurant (?)
Même sous linux, ou même en désactivant recall, tout le monde reste impacté. C'est pas seulement la machine qui fait tourner recall qui compte. C'est toute information qui passe par là. Envoyez un mail à quelqu'un qui utilise recall => votre mail y sera fiché. N'importe quelle information partagée est concernée, qu'elle soit publique ou privée.
Après Heartbleed l'industrie avait lancé la CII pour financer des projets open-source, mais ils se sont focalisé sur les projets directement liés à la sécurité (Heartbleed / openssl ayant focalisé l'attention).
Là, on voit bien qu'il faut une approche différente. Les attaquants ont certainement cherché des cibles du style "la petite lib d'xkcd", ie. le petit truc utilisé massivement (dont par certains packaging de sshd, cœur du problème ici) mais maintenu par un hobbyiste plus ou moins démotivé. C'est exactement ce genre de shortlist que l'industrie doit aussi faire de son côté: identifier toutes ces libs peu maintenues mais très utilisées. Et peut-être redonner vie à la CII...
Le
03/04/2024 à
09h
05
Pas besoin que ça soit dans le kernel Linux. Une backdoor dans OpenSSH touche déjà bien plus de machine intéressantes pour les pirates.
Quasiment tous ce qui permet le contrôle à distance par un technicien utilise OpenSSH aussi bien sous Linux, BSD, Mac et même possiblement Windows depuis quelques années. C'est à dire que presque tout serveurs et même une bonne partie des machines connectées auraient pu être compromis.
En l'occurrence l'attaque réduisait intentionnellement la portée aux .deb et .rpm, certainement pour éviter aux hackers d'avoir à "gérer" trop de familles *nix. Il faut voir que si pour une raison x ou y le build génère des problèmes non anticipés (par exemple car non testé sur un système donné par le hacker) ça risque de mettre tout son travail de sape à l'eau.
Le
02/04/2024 à
23h
24
d'autant que ce n'est pas le code de test qui est incriminé, mais les fichiers data, donc encore moins le genre de truc qu'on va auditer scrupuleusement (du moins jusqu'à aujourd'hui)
Le
02/04/2024 à
23h
17
Mais il existe du coup peut-être des portes dérobées dans d'autres paquets qui elles, n 'ont pas eu la chance d'être trouvées...
Il faut voir qu'une backdoor exploitée est aussi plus visible car l'exploitation laisse des traces, lève des alarmes etc. ce qui braque tout de suite les regards vers les composants susceptibles d'être compromis. Donc oui il y a certainement d'autres backdoors actives, mais a priori elles finissent par être repérées (à moins d'être dormantes / non exploitées), c'est une traque sans fin.
Perso j'ai ressorti mon atari st pour mon fils qui voulait voir à quoi ça ressemblait. L'émulation ne m'intéresse pas, mais ressortir des vieilleries ça a un certain charme... Le tac-tac-tac du lecteur de disquettes, le "insert disk 4", tout ça 🙂
J'étais surpris de voir qu'il fonctionne assez bien, certaines disquettes doivent être abîmées mais j'ai à peu près un jeu sur deux qui marche (déception je voulais relancer ishar 3 mais ça veut pas 😭)
J'y connais pas grand chose, mais le précédent article sur le PIIEC, et les infos que j'ai pu lire sur le site de la commission eu, donnaient en effet l'impression d'un investissement long et rigide, très planifié, pas franchement en phase avec l'industrie tech. Et d'y voir les usual suspects atos/orange aux premiers rangs renforce l'idée d'une énième pompe à argent public qui se dessine... J'espère juste avoir tort.
J'avoue que ... On voudrait faire un écran de fumée qu'on ne s'y prendrait pas autrement. Mais bon, ça arrive "très très concrètement", donc tout va bien.
Je suppose qu'effectivement, comme dans tout comité de standardisation , on se retrouve à devoir garder des archaïsmes et des fausses bonnes idées parceque certains y sont maladivement attachés.
Le CVSS est un format qui clairement est un peu parti dans tous les sens: on est passé d'un outil tentant de mesurer la gravité d'une vulnérabilité à un outil tentant de faire de la contextualisation et à servir de moyen pour faire de l'analyse de risque chez le client.
A cette dernière fin, on a ajouté et maintenu certains paramètres qui n'ont rien à voir ou ne devraient n'avoir rien à voir avec le score final d'une vulnérabilité, ce sont les valeurs "pense-bête" qu'on retrouve dans les valeurs supplémentaires.
Pour en revenir à l' "exploit maturity", il s'agit d'une métrique difficile à évaluer, et dont l'impact serait de minimiser le CVSS sur base d'informations non-fiables et pouvant varier rapidement. Dans la mesure où les fournisseurs ne veulent pas se risquer à évaluer cette métrique et préfèrent travailler sur base du scénario le plus pessimiste, on peut se demande pourquoi un tel champ existe, il aurait dû être éliminé comme les autres attributs temporels.
Dans le standard cvss, on a les valeurs de type "supplemental", qui n'impactent pas le score mais peuvent être utilisées par les utilisateurs pour stocker des informations complémentaires, cet endroit puisqu'il existe, serait la bonne place pour une notion comme la maturité de l'exploit.
Reste que l'ensemble des valeurs "supplemental" peuvent ressembler à une tentative de faire de la gestion de risque pour l'utilisateur, mais pour moi ça reste beaucoup trop insuffisant pour un contexte de grande entreprise est cela tente de mettre à plat un modèle qui devrait être plus adapté (dans une modèle relationnel, ces éléments seraient des attributs sur le lien entre une vulnérabilité et les contextes multiples où elle s'applique, tout comme les scores environnementaux)
Si je suis ce que tu dis, tu devrais voir d'un bon œil les distinctions entre les notes B/BT/BE/BTE, qui répond précisément à cette problématique de vouloir tout/trop intégrer. Les entreprises ayant une gestion du risque suffisamment élaborée peuvent se focaliser sur le score B en l'intégrant à leur propres analyses. Ça n'en rend pas moins les autres scores utiles à d'autres personnes dans d'autres situations ? Il me semble justement que l'approche modulaire/multiscore proposée permet d'adresser des use cases différents de façon assez transparente.
Le
03/12/2023 à
09h
14
J'ai pas lu tous les détails sur le site de FIRST, mais c'est tout de même une spec conçue avec pas mal d'acteurs du milieu (cf https://www.first.org/cvss/v4.0/specification-document#Appendix-A---Acknowledgments) donc j'imagine que les points soulevés ont été abondamment discutés. Il y a forcément des imperfections mais vu de l'extérieur, on ne mesure pas toujours l'ensemble des cas de figure, et pour les concepteurs il s'agit bien souvent de faire le moins mauvais choix.
Il y a aussi une FAQ sur le site, qui répond peut-être à certains points soulevés, ex. sur le "pourquoi c'est au consumer de remplir telle métrique" https://www.first.org/cvss/v4.0/faq#Why-is-this-the-responsibility-of-the-consumer-and-not-the-provider-vendor
(ah, les liens ne sont pas cliquables?)
Le
03/12/2023 à
09h
11
C'est vrai que l'article dénote une forme de point de vue, mais c'est normal puisqu'il s'agit d'une analyse et non d'une page de manuel. Je ne suis pas d'accord sur tout mais le mérite du texte est indéniable.
Personnellement, j'ai tendance à voir le CVSS 4.0 comme une amélioration même si je trouve, par exemple, que le Remediation Level aurait toute sa place dans 'base' et 'environnemental' et qu'"exploit maturity" aurait du disparaître car c'est une métrique dont l'évaluation est objectivement difficile et qui peut mener à des sous-évaluations de la menace.
J'ai pas lu tous les détails sur le site de FIRST, mais c'est tout de même une spec conçue avec pas mal d'acteurs du milieu (cf https://www.first.org/cvss/v4.0/specification-document#Appendix-A---Acknowledgments) donc j'imagine que les points soulevés ont été abondamment discutés. Il y a forcément des imperfections mais vu de l'extérieur, on ne mesure pas toujours l'ensemble des cas de figure, et pour les concepteurs il s'agit bien souvent de faire le moins mauvais choix.
Il y a aussi une FAQ sur le site, qui répond peut-être à certains points soulevés, ex. sur le "pourquoi c'est au consumer de remplir telle métrique" https://www.first.org/cvss/v4.0/faq#Why-is-this-the-responsibility-of-the-consumer-and-not-the-provider-vendor
Le
02/12/2023 à
07h
34
C'est intéressant d'avoir ce point de vue, et en même temps, c'est pas un peu gonflé d'accuser NVD de re-scoring lorsque délibérément on choisit de ne pas utiliser le framework qui normalise les scores?
D'autre part ça me paraît aussi plus sain que la note fournie par les mainteneurs puisse être challengée, et pas nécessairement reprise aveuglément
Pensez-vous que nous devrions limiter ou arrêter certaines thématiques ?
YOLO
Devrions-nous au contraire renforcer certaines thématiques ou en lancer de nouvelles ?
YOLO
Nos articles sont-ils souvent trop longs ?
YOLO
Faut-il rouvrir la salle B4 ?
Hein?
Autrement dit: faîtes vous plaisir, moi ça me va. Je préfère des articles écrits par passion / d’après vos centres d’intérêts, que sur commande en suivant juste le sens du vent.
Bon évidemment, faut de l’argent qui rentre, donc des lecteurs. Mais YOLO.
Ce que je note aussi c’est qu’il a fallu plus d’un an à la cnil pour réagir, alors que la violation de ses propres principes est ici plus que manifeste
Oui, mais c’est quoi l’intérêt de les mettre sur un GitHub public ?
Je saisis peut-être pas bien la question : pour du code open-source sur github, le repo va contenir les tests unitaires (ou autres), et doit pouvoir fonctionner en autonomie.
Pour répondre à @SebGF: si comme tu proposes les tests dépendent d’un gestionnaire de secrets ça complexifie la mise en place de l’environnement (y compris sur chaque machine de dev qui voudrait lancer localement les tests) et je ne suis pas sûr de voir le bénéfice au final
Précision : je ne parle pas d’un environnement de test persistant, mais bien d’un environnement qu’on setup et shutdown à la volée pour le test
Le
24/08/2023 à
14h
19
Il peut y avoir plein de raisons… Par exemple, pour tester une communication en mtls, il va falloir fournir des fakes certifs/clés
Le
23/08/2023 à
23h
26
J’ai des secrets (fake) dans mes tests unitaires, est-ce que je fais partie de ces “1 développeur sur 10” mauvais élève selon eux?
“Zero Trust” parce que Gigamon n’aurait pas accès à ce qui serait déchiffré, contrairement aux utilisateurs de sa ou ses solutions ?…
Même si c’est le cas ça implique de faire confiance en leur solution : d’une part qu’elle soit bien intentionnée, et d’autre part qu’elle n’ait aucune faille :-) En déchiffrant SSL autrement que pour le destinataire légitime, on augmente la surface d’attaque et on introduit un tiers supposément de confiance.
Sinon, je note qu’à défaut de mettre en avant ses solutions de SSL Decryption (bonne pioche, merci !), la VO de leur CP ne met pas WhatsApp en avant, mais titre sur le fait que “Nearly One Third of Security Breaches are Going Undetected by IT and Security Professionals” & relève que “70 percent lack visibility into encrypted data, a number that rises to 79 percent in Germany”…
Non pas que ça m’étonne (c’est du marketting malheureusement classique), mais employer le terme “lack of visibility” quand la question posée était “quelle est votre visibilité sur les données chiffrées”, ce n’est pas du tout neutre: bien sûr qu’on n’a pas de visibilité sur les données chiffrées … mais en même temps, est-ce que ce n’est pas un peu le but??
Le
21/07/2023 à
06h
25
D’ailleurs je trouve ça assez gonflé de parler de zero-trust en faisant de l’observabilité basée sur du déchiffrement SSL. C’est à peu près le contraire du zero-trust. (Trust nobody.. except me)
Le
21/07/2023 à
05h
34
« Il en va de même pour le trafic chiffré ; il est possible que les organisations négligent de reconnaître le danger majeur que ces données peuvent représenter, malgré les études qui ont montré que 93% des logiciels malveillants se cachent derrière un chiffrement. »
Quand j’ai lu ça je me suis dis non, ils vont quand même pas recommander d’éviter TLS?
En fait non, c’est pour vendre leur solution qui “déchiffre ssl”
Ravi de voir cette mouture tant attendue
Un truc qui me manque dans thunderbird jusque là, c’est la possibilité de synchroniser mes configs sur plusieurs installations, comme firefox sync. Par exemple, pour les filtres de messages, c’est relou de devoir propager ça manuellement entre mon laptop boulot et mon fixe, par exemple. J’avais entendu qu’ils bossaient là dessus pour supernova, est-ce que c’est dedans, du coup?
Il faudrait décerner une médaille à la frange crypto-libertarienne pour l’ensemble de son œuvre, championne pour faire parler d’elle et attirer des capitaux en brassant du vent.
Puis on mettrait une éolienne derrière chaque libertarien, pour qu’ils servent quand même à quelque chose.
Suite de l’histoire : Alma linux annonce se lancer et faire une “vraie” distro rhel-compatible basée sur centos stream, et plus un simple clone : https://almalinux.org/blog/future-of-almalinux/
Le
13/07/2023 à
06h
28
ragoutoutou a dit:
Pas tout à fait exact : en aval de centos streams, le code est restabilisé recontrôlé et potentiellement enrichi avec des backports spécifiques et des patches dédiés (pour des questions de stabilité ou de sécurité)… par exemple suite à un problème observé chez un client …
Mais si: bien sûr que RHEL est stabilisée, mais les patchs apportés pendant cette stabilisation sont versés sur l’upstream. C’est ce qui est expliqué dans le post que j’avais cité plus haut, et également dans le blog de redhat:
“When we develop fixes for issues in RHEL, we don’t just apply them to RHEL - they are applied upstream first, to projects like Fedora, CentOS Stream or the kernel project itself, and we then backport them.”
Ce côté “stable” de RHEL comparé à Streams ne provient que d’une chose: du cycle de release. Pas du code.
ragoutoutou a dit:
Une preuve simple à comprendre: comment Centos streams peut-il être l’upstream de RHEL quand, par exemple, Centos Streams 8 se retrouve EOL en mai 2024 alors que RHEL 8 aura encore des mises à jour jusqu’en 2029 …
En mai 2027, Il en sera de même pour RHEL 9.x qui continuera en phase de support 2 tandis que Centos Streams 9 s’arrêtera net.
Alors, je n’ai pas trouvé écrit noir sur blanc ce qui se passera en 2024 ou 2027, mais je ne vois pas en quoi ça changerait, et il ne faut pas confondre code source et releases. Le EOL de Streams signifie qu’il n’y aura plus de builds et de release. Mais la base de code étant la source de RHEL, elle va continuer à vivre, et pourra donc aussi être utilisée par les rebuilds - je ne vois pas pourquoi redhat changerait le process de build de RHEL à cause du EOL de Streams. Si c’était le cas en effet ce serait négatif pour l’open-source et le modèle poussé par redhat, mais je ne vois pas d’indice disant que ça fonctionnerait autrement après l’EOL de Streams.
Bref, il y a encore beaucoup de confusion .. ce qui n’est pas étonnant vu les erreurs qu’on peut lire partout. Cet article de nextinpact aussi en comporte quelques unes - j’en ai signalées hier mais pour l’instant je ne vois aucune modif de l’article. Ce que je relève:
“Les sources de CentOS Stream plus difficiles d’accès”
C’est faux: ce sont les sources du “vieux” centos (qui étaient jusque là maintenues pour les rebuilds) qui sont concernées.
“en verrouillant un peu plus CentOS Stream”
C’est faux: on confond ici CentOS Stream et RHEL. CentOS Stream n’est pas verrouillé. La polémique porte sur RHEL.
“Plus précisément, il faut cette licence pour accéder à tout ce qui est reversé par Red Hat dans le code de CentOS Stream, y compris les mises à jour de sécurité”
C’est encore faux: la licence permet d’accéder aux SRPMs de RHEL. Les sources “upstream”, qui sont celles de CentOS Stream, restent 100% accessibles. Et ce sont essentiellement les mêmes, y compris pour les mises à jour de sécurité, ou dans le cas spécifique d’un embargo, à la fin de la période d’embargo.
Il faut bien comprendre que la différence entre CentOS Stream et RHEL ne vient pas des sources (à part des éléments cosmétiques), mais bien du cycle de release et du support.
Le
12/07/2023 à
20h
32
Sur le plan purement juridique, je rejoins en fait le commentaire #20 sur le fait que le GPL est un peu trop fantasmée.
Sur le plan purement personnel, je considère que Red Hat fait une erreur. Surtout au niveau communication en considérant les rebuilds comme du pillage sans valeur ajoutée. Ce qui en soit est mensonger, insultant, et opposé au principe même du logiciel libre. Quand j’ai lu ce post de blog chez Red Hat, je me suis demandé s’ils ne découvraient ce qu’est le logiciel libre.
Et ça c’est une grosse erreur de mon point de vue car ça braque aussi les clients. Comme je disais dans mon précédent message, je connais des gros comptes qui ne veulent pas RHEL car ils ne veulent pas payer de license. Quand CentOS 8 a été flinguée et transformée en CentOS Stream, l’étude d’un remplaçant a été faite. Et la confiance en Red Hat était déjà très fragilisée. Cette confiance est encore plus fragilisée aujourd’hui et toute la famille Red Hat est désormais, sauf exception, absente des catalogues IT dans les secteurs où je preste.
Tu me diras que ça ne changera pas grand chose vu qu’ils se limitaient au strict nécessaire pour le besoin de RHEL. Ben y’a des décisions considérant ne plus vouloir utiliser leurs produits et ça devient désormais une clause bloquante pour un choix de solution si l’éditeur dit ne supporter que RHEL. A la suite de l’arrêt de CentOS, on a passé du temps à tester et qualifier les rebuilds pour s’assurer que le standard OS soit poursuivi avec tout le socle technique de la DSI. Ces travaux sont de nouveau à refaire.
Ce qui amène à un autre résultat : la stratégie de plusieurs DSI où je travaille est de s’orienter en priorité sur du Cloud-native application, donc du PaaS, et garder la VM pour du legacy. Ce changement imposé par Red Hat n’a fait qu’accélérer la volonté d’arrêter de faire de la VM pour ne plus avoir à maintenir un socle OS. Et le socle OS, bah maintenant c’est Ubuntu uniquement.
Et ça je trouve que c’est dommage car malgré quelques pieds dans le tapis dans son histoire, Red Hat a toujours eu de ma fenêtre une réputation positive. Depuis peu, c’est l’inverse que je constate et elle est rangée dans la même catégorie que Oracle ou IBM. Des entreprises avec qui on ne veut généralement pas travailler.
Je suis d’accord sur l’erreur de com et la mauvaise appréciation de la valeur des rebuilds. C’est certainement impossible de déterminer quelle est cette valeur pour redhat: est-ce que ça détourne de RHEL ou au contraire amène vers RHEL - et dans quelles proportions? Va savoir… J’ai vu passer des argumentaires sur reddit où la valeur était mesurée en fonction du nombre de contributions sur l’upstream (code, doc, …), et de ce point de vue elle était quasi nulle. Évidemment ce n’est qu’une partie de l’équation, sûrement négligeable même, comparé au fait d’habituer les utilisateurs à l’écosystème redhat. Donc on ne peut pas dire qu’il n’y a pas de valeur dans les rebuilds du point de vue de redhat, et à ce titre je n’ai pas bcp aimé non plus cette com. Qu’il y ait de la frustration de la part de certains de voir leur travail repris / réétiqueté pour peut-être en plus perdre des parts de marché, ça peut se comprendre occasionnellement (c’est humain), mais c’est le jeu de l’open-source et redhat n’est pas un nouveau venu dans ce domaine, c’est juste un sentiment qu’on doit savoir réprimer en tant que contributeur.
Maintenant, comme je disais, les rebuilds ne sont pas morts pour autant et sont encouragés à utiliser les “vraies” sources, celles de centos stream. RHEL est buildé via ces sources, donc n’importe quel linux peut faire de même, à partir des mêmes commits. D’ailleurs je serais curieux de savoir si c’est ce que Suse compte faire, ce serait une bonne nouvelle.
Pour l’autre point que tu soulèves, la stabilité : je connais mieux la théorie que la pratique, mais l’idée à la base de Stream est justement d’améliorer la stabilité et limiter les mauvaises surprises, notamment lors des upgrades : plutôt que de faire un saut dans l’inconnu à chaque major/minor, on est capable de tester via Stream plus ou moins en permanence et donc mieux anticiper les problèmes et remonter du feedback plus vite. J’imagine pour ça de déployer du rhel ou rocky/alma en prod, et stream sur certains environnements de test. Après, je fais ni de la prod ni du linux, j’ai sûrement une vue incomplète des choses…
Le
12/07/2023 à
17h
00
Sachant que la GPL 2.0 ne spécifie rien qu’autre que “machine readable source code (…) on a medium customarily used for software interchange”.
Même si Red Hat a un passif de mesures borderline avec la GPL, ça sert à rien de pinailler sur des détails comme celui-ci.
Oui si on s’en tient strictement au respect de la GPL, mais ce qui me chagrine c’est le ressentiment qu’on voit ici, alors qu’en définitive je trouve que c’est un mauvais procès qui est fait dans la mesure où les sources utilisées pour builder RHEL restent bel et bien 100% open.
Je pense surtout qu’il y a eu des maladresses de com dans la façon de considérer les rebuilds (et je vais glisser un petit disclaimer ici: je bosse pour redhat (pas dans cette branche, pas dans les linux - et je ne sais rien de plus là dessus que ce que je lis dans la presse) mais je reste très attaché aux questions sur l’open-source - et d’autant plus regardant sur les changements de politiques de la boite).
Quand on s’en tient à regarder les process de build, honnêtement, cette décision a du sens: on supprime un repo qui n’avait a priori plus d’utilité pour redhat, et qui était juste gracieusement maintenu pour les rebuilds. La question d’un point de vue entreprise était bel est bien de savoir si ces rebuilds aident ou desservent redhat. J’imagine, pas simple à répondre. Évidemment d’un point de vue communauté, la question ne se pose pas dans ces termes, et la fermeture des repos apparaît forcément défavorable. Sauf que: redhat veut pousser la communauté vers centos stream. Non pas que les utilisateurs, mais les rebuilds également: ça signifie que les rebuilders doivent (selon redhat) prendre stream comme source, et avec un peu de chance, du fait d’en être plus proche, y contribuer. Je ne sais pas si ça en prendra le chemin …. pas sûr vu les déclarations des uns et des autres. Mais toujours est-il que ces questions sont finalement assez loin des procès en “closed-source” faits à redhat.
C’est assez drôle, de sortir un article datant de 2011 dans lequel il est reproché à redhat de fournir les sources dans un gros tarball plutôt que dans git … alors que c’est précisément le contraire aujourd’hui (et ce qu’on lui reproche, il faut croire qu’on aime reprocher tout et son contraire) : maintenant avec centos stream toutes les sources sont dispo en mode “upstream first”, bien au propre dans git, avec l’historique qui va bien.
292 commentaires
Linux est aujourd'hui le premier système d'exploitation sur Microsoft Azure
Le 25/07/2024 à 18h 49
1000 distros?? Ça doit être en comptant différentes versions / peut-être différentes archis, sinon je vois pas ...
Fiasco CrowdStrike : Microsoft persiste et signe, tout est la faute de l'Europe
Le 25/07/2024 à 07h 12
Donc le bug était côté linux/redhat.
Pour moi ça ne remet pas en cause la meilleure pertinence de l'approche ebpf/sandboxée, a l'opposé de ce que fait windows aujourd'hui. Évidemment il faut que le socle (côté linux/kernel) soit en béton armé, mais ça sécurise énormément les choses en cas de souci côté éditeur tiers.
(D'ailleurs ebpf pour windows existe, peut-être qu'il manque de maturité mais ça peut être la solution à l'avenir)
Panne CrowdStrike : comment une simple mise à jour a-t-elle entrainé une telle pagaille ?
« C’est le stagiaire qui… »
Le 24/07/2024 à 19h 01
cf https://www.brendangregg.com/blog/2024-07-22/no-more-blue-fridays.html
Le 21/07/2024 à 23h 18
Le hook noyau / eBPF est sensé être sûr (code exécuté dans une sandbox, et passé par un vérificateur), et d'ailleurs crowdstrike sur linux semble fonctionner ainsi. Donc a priori, plus safe que sous windows... sauf que même comme ça, ils parviennent à déclencher un kernel paniccf red hat qui a eu un problème similaire en juin https://access.redhat.com/solutions/7068083 - un patch côté kernel a corrigé le vérificateur eBPF pour ça.
[MàJ] Fiasco CrowdStrike : détails techniques, 8,5 millions de machines touchées selon Microsoft
78 minutes ont suffi
Le 20/07/2024 à 14h 52
La question qui tue maintenant, c'est : est-ce que ce désastre sera suffisant pour que cette entreprise à $74Mds se dise que ce serait peut-être bien de (mieux) tester ses màj? Vu la com assez laconique, on peut se poser la question.[MàJ] LAION-5B : des photos d'enfants utilisées sans consentement pour entrainer des IA
IA pas de consentement
Le 03/07/2024 à 22h 06
Publiquement accessible ne signifie qu'on peut légalement en faire ce qu'on veut.C'est très bien d'avoir une hygiène numérique, ça n'excuse pas pour autant la réutilisation sans consentement ... a priori la question du droit d'auteur sur le matériel d'entraînement n'est pas tranchée (?)
Mastodon : les chercheurs n'ont finalement pas migré en masse
Comme un Mammouth sans aile
Le 13/06/2024 à 13h 59
J'ai pas lu l'étude elle-même mais je suppose que l'argument de la courbe d'apprentissage concerne les collègues qu'on n'a pas réussi à débaucher de twitterAdobe assure que ses modèles d'IA Firefly Gen ne sont pas entrainés sur des données utilisateurs
Ia pas d'entrainement
Le 10/06/2024 à 20h 19
"On ne fera XYZ que dans les limites imposées par la loi"Ok mais, par définition, ça aurait été illégal sinon. Donc je vois pas en quoi c'est rassurant (?)
La surveillance Windows Recall permet en l’état un pillage des données sensibles
Buffet à volonté
Le 04/06/2024 à 12h 39
Même sous linux, ou même en désactivant recall, tout le monde reste impacté. C'est pas seulement la machine qui fait tourner recall qui compte. C'est toute information qui passe par là. Envoyez un mail à quelqu'un qui utilise recall => votre mail y sera fiché. N'importe quelle information partagée est concernée, qu'elle soit publique ou privée.XZ Utils : comment une porte dérobée dans un composant de Linux a fait craindre le pire
panicattack.gif
Le 03/04/2024 à 18h 26
Là, on voit bien qu'il faut une approche différente. Les attaquants ont certainement cherché des cibles du style "la petite lib d'xkcd", ie. le petit truc utilisé massivement (dont par certains packaging de sshd, cœur du problème ici) mais maintenu par un hobbyiste plus ou moins démotivé. C'est exactement ce genre de shortlist que l'industrie doit aussi faire de son côté: identifier toutes ces libs peu maintenues mais très utilisées. Et peut-être redonner vie à la CII...
Le 03/04/2024 à 09h 05
Le 02/04/2024 à 23h 24
d'autant que ce n'est pas le code de test qui est incriminé, mais les fichiers data, donc encore moins le genre de truc qu'on va auditer scrupuleusement (du moins jusqu'à aujourd'hui)Le 02/04/2024 à 23h 17
Il faut voir qu'une backdoor exploitée est aussi plus visible car l'exploitation laisse des traces, lève des alarmes etc. ce qui braque tout de suite les regards vers les composants susceptibles d'être compromis. Donc oui il y a certainement d'autres backdoors actives, mais a priori elles finissent par être repérées (à moins d'être dormantes / non exploitées), c'est une traque sans fin.
Discord permet aux créateurs de diffuser de la publicité
Le 03/04/2024 à 07h 44
Discord est déjà un enfer de bruits et de popups en tout genre, hâte de voir ce que ça va donner avec de la pub en plus 🤣WordPad disparaitra de Windows 11 avec la mise à jour 24H2
Le 29/03/2024 à 07h 33
Bon sinon y'a LibreOffice ou [insérer autre alternative ici], c'est pas comme si le choix manquait 😉
Les États-Unis attaquent Apple pour abus de position dominante
Le 22/03/2024 à 11h 38
Alibaba s'est tout de même mangé 2.8 milliards d'amende en Chine pour pratiques monopolistiques, et maintenant sous le coup d'un plan de scission.[Édito] Internet, un annuaire des Français à ciel ouvert
Et si on se donnait les moyens de bien faire ?
Le 16/03/2024 à 08h 46
On peut voir le verre à moitié plein, sinon: il ne reste plus grand chose à nous dérober, c'est plutôt positif!Ressortez les consoles du siècle dernier et savourez le néo-rétro
Parce qu’on en a marre de souffler sur les PCB des vieilles cartouches. On veut du neuf !
Le 24/01/2024 à 19h 38
Perso j'ai ressorti mon atari st pour mon fils qui voulait voir à quoi ça ressemblait. L'émulation ne m'intéresse pas, mais ressortir des vieilleries ça a un certain charme... Le tac-tac-tac du lecteur de disquettes, le "insert disk 4", tout ça 🙂J'étais surpris de voir qu'il fonctionne assez bien, certaines disquettes doivent être abîmées mais j'ai à peu près un jeu sur deux qui marche (déception je voulais relancer ishar 3 mais ça veut pas 😭)
Projet européen sur le cloud : OVHcloud s'est retirée au dernier moment et s’explique
Tu me vois, tu ne me vois plus
Le 11/12/2023 à 21h 00
J'y connais pas grand chose, mais le précédent article sur le PIIEC, et les infos que j'ai pu lire sur le site de la commission eu, donnaient en effet l'impression d'un investissement long et rigide, très planifié, pas franchement en phase avec l'industrie tech. Et d'y voir les usual suspects atos/orange aux premiers rangs renforce l'idée d'une énième pompe à argent public qui se dessine... J'espère juste avoir tort.Cloud : 1,2 milliard d’euros pour un Projet important d'intérêt européen commun
Le 08/12/2023 à 21h 43
on va pas se plaindre de voir une nouvelle tête au milieu des usual suspects :-)Gaia-X « vit toujours » et « arrive à des étapes très concrètes »
Le 04/12/2023 à 23h 05
J'avoue que ... On voudrait faire un écran de fumée qu'on ne s'y prendrait pas autrement. Mais bon, ça arrive "très très concrètement", donc tout va bien.CVSS 4.0 : dur, dur, d’être un expert !
C’est comme CVSS 5.0 mais en moins bien
Le 03/12/2023 à 19h 54
Le 03/12/2023 à 09h 14
Le 03/12/2023 à 09h 11
Il y a aussi une FAQ sur le site, qui répond peut-être à certains points soulevés, ex. sur le "pourquoi c'est au consumer de remplir telle métrique" https://www.first.org/cvss/v4.0/faq#Why-is-this-the-responsibility-of-the-consumer-and-not-the-provider-vendor
Le 02/12/2023 à 07h 34
C'est intéressant d'avoir ce point de vue, et en même temps, c'est pas un peu gonflé d'accuser NVD de re-scoring lorsque délibérément on choisit de ne pas utiliser le framework qui normalise les scores?D'autre part ça me paraît aussi plus sain que la note fournie par les mainteneurs puisse être challengée, et pas nécessairement reprise aveuglément
Quoi de neuf à la rédac’ #7
MàJ : Flock dans mon (e)bureau, faut qu’on parle de cette illustration !
Le 11/11/2023 à 21h 03
“Flock en stock” 👌
Très bonne chose ces dessins/montages, pour renforcer l’identité du site
Le poing dev 3 – Patch Tuesday du Tuesday soir
Mais pourquoi sont-ils si performants ??
Le 07/11/2023 à 08h 10
1000 bravos pour la transparence et le côté participatif, c’est trop rare aujourd’hui de voir ça
Quoi de neuf à la rédac #4 : par où commencer…
Par le début ?
Le 21/10/2023 à 20h 56
Autrement dit: faîtes vous plaisir, moi ça me va. Je préfère des articles écrits par passion / d’après vos centres d’intérêts, que sur commande en suivant juste le sens du vent.
Bon évidemment, faut de l’argent qui rentre, donc des lecteurs. Mais YOLO.
Cloud : au Royaume-Uni, AWS et Microsoft pointés du doigt pour leurs effets délétères sur la concurrence
Une enquête officiellement ouverte
Le 16/10/2023 à 11h 46
Suite au prochain épisode dans 5 à 10 ans
Faille critique WebP : les dangers d'une mauvaise communication
C'est pas moi, c'est...
Le 02/10/2023 à 16h 52
Les ingénieurs de google qui publient les CVE devraient peut-être discuter avec les ingénieurs de google qui publient des white-papers sur les transparence en sécurité ? Genre comme ici: https://www.securityweek.com/google-proposes-more-transparent-vulnerability-management-practices/
Next INpact change de propriétaire : au revoir chère communauté ;-)
C'est par le bien-être que se crée le bien-faire
Le 26/09/2023 à 05h 45
Je suis pas très bon en message d’au-revoir, alors juste : merci pour tout!! 😘
[MàJ] Jeux vidéo : après s’être vidé un chargeur dans le pied, le moteur Unity fait volte-face
Sabordage
Le 18/09/2023 à 22h 04
La légalité pose question :
À moins qu’ils fassent machine arrière, on peut parier qu’il y aura des procès et enquêtes
Le 18/09/2023 à 20h 33
Unity réfléchirait désormais à capper leur ponction selon les revenus générés par les développeurs : https://arstechnica.com/gaming/2023/09/report-unity-considering-revenue-based-fee-caps-self-reported-install-numbers/
Ça se rapprocherait finalement du modèle de l’unreal engine, en un peu plus usine à gaz tout de même.
Prise en main de Bluesky : un dérivé de Twitter décentralisé, qui dépasse le million d’utilisateurs
Tour du propriétaire
Le 13/09/2023 à 17h 57
J’allais le dire :-)
Visiblement la sécurité y est prise à la légère
https://fosstodon.org/@north/111057335768073441
Boursorama demande les identifiants et mots de passe des impôts, la CNIL la met en demeure
Je vous demande de vous arrêter !
Le 30/08/2023 à 17h 19
Ce que je note aussi c’est qu’il a fallu plus d’un an à la cnil pour réagir, alors que la violation de ses propres principes est ici plus que manifeste
Les commits publics de GitHub recèlent « au moins 10 millions de secrets »
Le 24/08/2023 à 17h 50
C’est du code de test, donc pas du code mort (?)
Le 24/08/2023 à 16h 31
Je saisis peut-être pas bien la question : pour du code open-source sur github, le repo va contenir les tests unitaires (ou autres), et doit pouvoir fonctionner en autonomie.
Pour répondre à @SebGF: si comme tu proposes les tests dépendent d’un gestionnaire de secrets ça complexifie la mise en place de l’environnement (y compris sur chaque machine de dev qui voudrait lancer localement les tests) et je ne suis pas sûr de voir le bénéfice au final
Précision : je ne parle pas d’un environnement de test persistant, mais bien d’un environnement qu’on setup et shutdown à la volée pour le test
Le 24/08/2023 à 14h 19
Il peut y avoir plein de raisons… Par exemple, pour tester une communication en mtls, il va falloir fournir des fakes certifs/clés
Le 23/08/2023 à 23h 26
J’ai des secrets (fake) dans mes tests unitaires, est-ce que je fais partie de ces “1 développeur sur 10” mauvais élève selon eux?
Pourquoi 69 % des RSSI français auraient-ils interdit l’utilisation de WhatsApp ?
Le 21/07/2023 à 15h 08
Même si c’est le cas ça implique de faire confiance en leur solution : d’une part qu’elle soit bien intentionnée, et d’autre part qu’elle n’ait aucune faille :-) En déchiffrant SSL autrement que pour le destinataire légitime, on augmente la surface d’attaque et on introduit un tiers supposément de confiance.
Non pas que ça m’étonne (c’est du marketting malheureusement classique), mais employer le terme “lack of visibility” quand la question posée était “quelle est votre visibilité sur les données chiffrées”, ce n’est pas du tout neutre: bien sûr qu’on n’a pas de visibilité sur les données chiffrées … mais en même temps, est-ce que ce n’est pas un peu le but??
Le 21/07/2023 à 06h 25
D’ailleurs je trouve ça assez gonflé de parler de zero-trust en faisant de l’observabilité basée sur du déchiffrement SSL. C’est à peu près le contraire du zero-trust. (Trust nobody.. except me)
Le 21/07/2023 à 05h 34
Quand j’ai lu ça je me suis dis non, ils vont quand même pas recommander d’éviter TLS?
En fait non, c’est pour vendre leur solution qui “déchiffre ssl”
J’imagine que s’ils tapent si fort sur WhatsApp & co, c’est que ces protocoles échappent à leur surveillance
Thunderbird 115 Supernova : une vraie version majeure aux multiples améliorations
Une nouvelle disposition « cachée »
Le 20/07/2023 à 20h 55
Ravi de voir cette mouture tant attendue
Un truc qui me manque dans thunderbird jusque là, c’est la possibilité de synchroniser mes configs sur plusieurs installations, comme firefox sync. Par exemple, pour les filtres de messages, c’est relou de devoir propager ça manuellement entre mon laptop boulot et mon fixe, par exemple. J’avais entendu qu’ils bossaient là dessus pour supernova, est-ce que c’est dedans, du coup?
Où en est le web3 ?
Et puis d'abord, c'est quoi ?
Le 19/07/2023 à 20h 25
Il faudrait décerner une médaille à la frange crypto-libertarienne pour l’ensemble de son œuvre, championne pour faire parler d’elle et attirer des capitaux en brassant du vent.
Puis on mettrait une éolienne derrière chaque libertarien, pour qu’ils servent quand même à quelque chose.
Le 19/07/2023 à 20h 13
Web4?
Tu as un train de retard, l’avenir est dans le web5 https://coinacademy.fr/actu/crypto-jack-dorsey-projet-web5/
Red Hat : bisbilles autour du code source de CentOS Stream, Oracle et SUSE s'en mêlent
Ambiance
Le 17/07/2023 à 05h 38
Suite de l’histoire : Alma linux annonce se lancer et faire une “vraie” distro rhel-compatible basée sur centos stream, et plus un simple clone : https://almalinux.org/blog/future-of-almalinux/
Le 13/07/2023 à 06h 28
Mais si: bien sûr que RHEL est stabilisée, mais les patchs apportés pendant cette stabilisation sont versés sur l’upstream. C’est ce qui est expliqué dans le post que j’avais cité plus haut, et également dans le blog de redhat:
Ce côté “stable” de RHEL comparé à Streams ne provient que d’une chose: du cycle de release. Pas du code.
Alors, je n’ai pas trouvé écrit noir sur blanc ce qui se passera en 2024 ou 2027, mais je ne vois pas en quoi ça changerait, et il ne faut pas confondre code source et releases. Le EOL de Streams signifie qu’il n’y aura plus de builds et de release. Mais la base de code étant la source de RHEL, elle va continuer à vivre, et pourra donc aussi être utilisée par les rebuilds - je ne vois pas pourquoi redhat changerait le process de build de RHEL à cause du EOL de Streams. Si c’était le cas en effet ce serait négatif pour l’open-source et le modèle poussé par redhat, mais je ne vois pas d’indice disant que ça fonctionnerait autrement après l’EOL de Streams.
Bref, il y a encore beaucoup de confusion .. ce qui n’est pas étonnant vu les erreurs qu’on peut lire partout. Cet article de nextinpact aussi en comporte quelques unes - j’en ai signalées hier mais pour l’instant je ne vois aucune modif de l’article. Ce que je relève:
C’est faux: ce sont les sources du “vieux” centos (qui étaient jusque là maintenues pour les rebuilds) qui sont concernées.
C’est faux: on confond ici CentOS Stream et RHEL. CentOS Stream n’est pas verrouillé. La polémique porte sur RHEL.
C’est encore faux: la licence permet d’accéder aux SRPMs de RHEL. Les sources “upstream”, qui sont celles de CentOS Stream, restent 100% accessibles. Et ce sont essentiellement les mêmes, y compris pour les mises à jour de sécurité, ou dans le cas spécifique d’un embargo, à la fin de la période d’embargo.
Il faut bien comprendre que la différence entre CentOS Stream et RHEL ne vient pas des sources (à part des éléments cosmétiques), mais bien du cycle de release et du support.
Le 12/07/2023 à 20h 32
Je suis d’accord sur l’erreur de com et la mauvaise appréciation de la valeur des rebuilds. C’est certainement impossible de déterminer quelle est cette valeur pour redhat: est-ce que ça détourne de RHEL ou au contraire amène vers RHEL - et dans quelles proportions? Va savoir… J’ai vu passer des argumentaires sur reddit où la valeur était mesurée en fonction du nombre de contributions sur l’upstream (code, doc, …), et de ce point de vue elle était quasi nulle. Évidemment ce n’est qu’une partie de l’équation, sûrement négligeable même, comparé au fait d’habituer les utilisateurs à l’écosystème redhat. Donc on ne peut pas dire qu’il n’y a pas de valeur dans les rebuilds du point de vue de redhat, et à ce titre je n’ai pas bcp aimé non plus cette com. Qu’il y ait de la frustration de la part de certains de voir leur travail repris / réétiqueté pour peut-être en plus perdre des parts de marché, ça peut se comprendre occasionnellement (c’est humain), mais c’est le jeu de l’open-source et redhat n’est pas un nouveau venu dans ce domaine, c’est juste un sentiment qu’on doit savoir réprimer en tant que contributeur.
Maintenant, comme je disais, les rebuilds ne sont pas morts pour autant et sont encouragés à utiliser les “vraies” sources, celles de centos stream. RHEL est buildé via ces sources, donc n’importe quel linux peut faire de même, à partir des mêmes commits. D’ailleurs je serais curieux de savoir si c’est ce que Suse compte faire, ce serait une bonne nouvelle.
Pour l’autre point que tu soulèves, la stabilité : je connais mieux la théorie que la pratique, mais l’idée à la base de Stream est justement d’améliorer la stabilité et limiter les mauvaises surprises, notamment lors des upgrades : plutôt que de faire un saut dans l’inconnu à chaque major/minor, on est capable de tester via Stream plus ou moins en permanence et donc mieux anticiper les problèmes et remonter du feedback plus vite. J’imagine pour ça de déployer du rhel ou rocky/alma en prod, et stream sur certains environnements de test. Après, je fais ni de la prod ni du linux, j’ai sûrement une vue incomplète des choses…
Le 12/07/2023 à 17h 00
Oui si on s’en tient strictement au respect de la GPL, mais ce qui me chagrine c’est le ressentiment qu’on voit ici, alors qu’en définitive je trouve que c’est un mauvais procès qui est fait dans la mesure où les sources utilisées pour builder RHEL restent bel et bien 100% open.
Je pense surtout qu’il y a eu des maladresses de com dans la façon de considérer les rebuilds (et je vais glisser un petit disclaimer ici: je bosse pour redhat (pas dans cette branche, pas dans les linux - et je ne sais rien de plus là dessus que ce que je lis dans la presse) mais je reste très attaché aux questions sur l’open-source - et d’autant plus regardant sur les changements de politiques de la boite).
Quand on s’en tient à regarder les process de build, honnêtement, cette décision a du sens: on supprime un repo qui n’avait a priori plus d’utilité pour redhat, et qui était juste gracieusement maintenu pour les rebuilds. La question d’un point de vue entreprise était bel est bien de savoir si ces rebuilds aident ou desservent redhat. J’imagine, pas simple à répondre. Évidemment d’un point de vue communauté, la question ne se pose pas dans ces termes, et la fermeture des repos apparaît forcément défavorable. Sauf que: redhat veut pousser la communauté vers centos stream. Non pas que les utilisateurs, mais les rebuilds également: ça signifie que les rebuilders doivent (selon redhat) prendre stream comme source, et avec un peu de chance, du fait d’en être plus proche, y contribuer. Je ne sais pas si ça en prendra le chemin …. pas sûr vu les déclarations des uns et des autres. Mais toujours est-il que ces questions sont finalement assez loin des procès en “closed-source” faits à redhat.
Le 12/07/2023 à 16h 10
C’est assez drôle, de sortir un article datant de 2011 dans lequel il est reproché à redhat de fournir les sources dans un gros tarball plutôt que dans git … alors que c’est précisément le contraire aujourd’hui (et ce qu’on lui reproche, il faut croire qu’on aime reprocher tout et son contraire) : maintenant avec centos stream toutes les sources sont dispo en mode “upstream first”, bien au propre dans git, avec l’historique qui va bien.