Couper des câbles, ce n'est pas cyber (sauf si on a employé des robots pour le faire ).
Par contre, un réseau Internet dégradé en France, ça pourrait ensuite faciliter certaines attaques cyber.
Couper des câbles, ce n'est pas cyber, mais l'impact lui, est cyber et peut donc rentrer dans les prérogatives de l'ANSSI ;)
Le
29/07/2024 à
14h
21
Je me demande pourquoi avoir contacté l'ANSSI, l'attaque n'étant pas une cyberattaque. Le ministère de l'intérieur était plus approprié. Darmanin aurait dit qu'ils avaient déjà identifié des coupables, suspects, un certain nombre de profils qui auraient pu commettre les sabotages.
Parce qu'il pourrait ou aurait pu s'agir d'une cyberattaque. C'est le genre de technique qui pourrait être utilisée pour déstabiliser un pays.
De plus, et surtout si c'est un groupe étatique qui est derrière, rien n'empêche de profiter que plusieurs tronçons soient HS pour venir y foutre des boites noires qui vont venir épier le réseau (comment ça, je suis parano ? ). Un moyen de faire diversion pour installer ce que l'on veut ailleurs...
Ou un moyen de diversion pour autre chose. Tout est imaginable. Et si certains scénarii peuvent ressembler à de la science fiction, la réalité a su montrer par le passé qu'elle pouvait largement la dépasser dans certains cas (duplication à distance d'un écran à tube cathodique, écoute sonore sur les vibrations d'une ampoule électrique, reconnaissance de saisie clavier par écoute des sons émis par les touches, retour SAV vérolé et j'en passe !)
Le
29/07/2024 à
10h
38
La différence c’est que la dernière fois c’était trois câbles au même endroit Là on parle de 4 endroits différents dans toute la France, on ne sait même pas le nombre de câbles concernés. C’est beaucoup plus embêtant, nous on a des villes dans le noir avec des coupures à plus de 800km les unes des autres, et nous ne sommes pas les seuls.
J'allais écrire presque la même chose que Ferd. Je trouve juste sur le site de Le Monde que les sabotages noctures ont eu lieu dans 6 départements. Donc, a priori, ce serait non pas 4, mais 6 sabotages ?
[edit] Ajout de la partie en italique, qui pouvait prêter à confusion sans.
Je me suis posé la même question. J'ai hésité, et comme le nom complet de la catégorie c'est "IA & algorithmes" j'ai laissé. Mais oui, ça m'a surpris aussi.
Certes. Mais ce mécanisme a finalement été autorisé pour les sites pornographiques ;)
Ah ? J'en étais resté à l'épisode où l'Arcom avait dit "Nope".
Après avoir cherché viteuf, effectivement une expérimentation lancée en avril de cette année.
Débile, un mineur peut en détenir une...
Débile oui et non. C'est un oui par dépits : c'est pas une solution optimale, mais c'est tellement difficile d'avoir un truc qui soit à la fois efficace & respectueux de la vie privée que cela en est quasiment impossible techniquement.
Le
27/07/2024 à
11h
46
, ainsi qu'à me donner ton numéro de carte bancaire pour m'assurer que tu es majeur
Échec :p
Non reconnu comme preuve de majorité, un mineur peut en détenir une.
De toute façon tu le connais mon numéro de CB, y'a ton nom marqué sur la mienne.
Ah, ça fallait peut-être pas le dire
Non reconnu comme preuve de majorité, un mineur peut en détenir une.
Certes. Mais ce mécanisme a finalement été autorisé pour les sites pornographiques ;)
Ah, ça fallait peut-être pas le dire
Ouais ben chéri, rend moi ma carte bleue
Le
27/07/2024 à
10h
02
Bah en l'absence de détails, on ne peut que supposer. Et compte tenu de l'historique de ces entreprises, ma supposition par défaut est qu'ils prennent tout et disent aux personnes de se justifier pourquoi elles ne devraient pas se faire violer leur vie privée.
La routine habituelle.
De l'arbitraire pur, encore et toujours.
J'essaie juste de comprendre comment une entité de cette taille et qui est sous surveillance peut se lancer dans ce genre d'initiative alors que le RGPD est entrée en application en Europe depuis 6 ans maintenant et que le moindre écart va être vite sanctionné.
Bof. Ils sont installés dans le pays de l'APD qui a les couilles dans un étau (puisque l'économie de son pays dépend des multinationales étrangères) et donc un pouvoir presque nul. Je n'ai pas vérifié, mais je suppose que X est aussi installé en Irlande.
Quand le bâton de la sanction est une matraque en mousse, ça fini forcément en fête du slip.
On peut voir cela comme une "évolution" des captchas qui ont largement servi à entrainer des modèles d'IA de reconnaissance de texte.
Plutôt la reconnaissance d'image pour le coup, même si ua début c'était beaucoup du texte.
Encore une belle idée de merde, n'empêche...
J'adore la société vue par le Web n'empêche : tout le monde est un robot par défaut, tout le monde doit être considéré comme mineur par défaut vu que législation l'impose, et tout le monde doit servir de matière première à entraîner des modèles de machine learning. Manque plus que tout le monde qui doit servir à nourrir la population à la fin et on aura terminé la boucle.
Bah en l'absence de détails, on ne peut que supposer. Et compte tenu de l'historique de ces entreprises, ma supposition par défaut est qu'ils prennent tout et disent aux personnes de se justifier pourquoi elles ne devraient pas se faire violer leur vie privée.
Pour une entreprise qui ferait des bénéfices colossaux comme Meta ou Alphabet, j'approuverai à 100% (surtout que le bénéfice engrengeable peut être supérieur au montant de l'amende, surtout si on prend en compte le temps de l'enquête, etc.
Pour X, qui est déficitaire depuis le rachat par Musk, il faudrait être complètement idiot pour se tirer une telle balle dans le pied (mais bon, presque plus rien ne m'étonne aujourd'hui).
Quand le bâton de la sanction est une matraque en mousse, ça fini forcément en fête du slip
C'est vrai. Sauf que justement le DPC (la CNIL Irlandaise) s'est faite remontée le slip aussi bien en interne (par des institutions irlandaises donc), par ses consoeurs que par l'Europe. la DPC devait embaucher (je ne sais pas où cela en est), mais elle est sous étroite surveillance et ne peut plus êtes aussi laxiste qu'auparavant.
Et après vérification, le siège social de X en Europe semble être à Dublin (donc en Irlande, effectivement).
Plutôt la reconnaissance d'image pour le coup, même si ua début c'était beaucoup du texte.
Au début, et pour le captcha de Google (je passe l'époque du captcha pur et dur qui ne servait que de captcha), on avait des images qui correspondaient notamment à des numéros de rue. En interne, c'était en réalité des images prises de Street View pour pouvoir reconnaitre localiser précisément les numéro dans les rues.
Ensuite, effectivement, on a eu les images (cliquez sur les girafes, ou sélectionnez les images où il y a un feu tricolore). Là encore, en vue d'entrainer des IA à faible coût.
tout le monde est un robot par défaut, tout le monde doit être considéré comme mineur par défaut vu que législation l'impose,
D'ailleurs, rien me prouve que je discute avec un être humain adulte et pas un robot mineur :p Donc en captcha, je t'invite à aller faire un tape m-en 5 avec Ness et à me dire le résultat, ainsi qu'à me donner ton numéro de carte bancaire pour m'assurer que tu es majeur (qui ne tente rien n'a rien )
[edit] Plus sérieuement, sur la dernière partie, je suis entièrement d'accord avec toi. De mon constat, ce qui détruit vraiment le web, ce sont les réseaux sociaux (enfin surtout l'usage qu'on en fait). Il semble bien loin le web du début des années 2000... Le web, c'est comme les moulins : c'était mieux à vent !
Le
27/07/2024 à
00h
49
Vu que le traitement parle des "interactions utilisateurs", il va forcément avoir les noms d'utilisateur puisque le principe est de mentionner le destinataire dans le post. Et ceux-ci sont considérés comme donnée personnelle indirectement identifiante. Voire directe si la personne poste sous sa véritable identité.
Donc cela ne peut être de l'opt-in par défaut.
Mais de toute façon ils s'en foutent. Perso j'ai choisi la solution qui me sied le mieux : refuser d'ouvrir un lien qui va vers ces sites.
Même si cela ne sert pas à grand chose puisque les éviter est quasi impossible. Y compris ici avec des saletés d'intégrations dans les articles.
Je n'ai pas compris "interactions utilisateurs" comme le fait de mentionner un utilisateur, mais comme le fait de lire les tweets d'un utilisateur. Mais peut être que je me trompe.
Après, retirer la mention de l'utilisateur (en gros, "anonymiser") d'un tweet est facile. Il s'agit ici d'entrainer et d'ajuster leur IA. Ce qui importe alors est le contenu, pas les métadonnées.
Encore une fois, cela n'enlève rien au fait que je trouve cette manière de procéder pitoyable. Et je ne cherche pas à les défendre. J'essaie juste de comprendre comment une entité de cette taille et qui est sous surveillance peut se lancer dans ce genre d'initiative alors que le RGPD est entrée en application en Europe depuis 6 ans maintenant et que le moindre écart va être vite sanctionné.
C'est la seule explication "valable" que je vois. On peut voir cela comme une "évolution" des captchas qui ont largement servi à entrainer des modèles d'IA de reconnaissance de texte.
Le
26/07/2024 à
18h
49
Juste pour rappel, le RGPD concernent les données à caractère personnel. Toute donnée n'est pas forcément une donnée personnelle.
Je suppose que X et Meta partent du principe qu'un post utilisateur n'est pas a priori une donnée personnelle (même si elle peut éventuellement l'être). Dans le cas contraire, un consentement explicite en opt-in me parait effectivement obligatoire.
Quoi qu'il en soit, cela n'empêche pas cette pratique d'être abjecte.
Je pense que l'idée est d'avoir une phrase non sémantiquement significative (une sorte de signature unique) qui soit unique pour chaque texte que l'on veut protéger.
Si l'IA est capable de repondre la "signature", alors c'est qu'elle est passée sur le texte.
Maintenant, cela sous-entend que le jeu de données d'entrainement est empoisonné. Ce qui est loin d'être évident, car en IA, la qualité d'entrainement des modèles dépend fortement de la qualité du jeu d'entrainement. Donc en général, une attention particulière est portée à cela. Et comme le dit l'article, ce genre de modification est assez facilement détectable, même automatiquement. Donc bon...
J'ai demandé à COPILOT => réponse "il faut une juste mesure entre les bénéfices et effets negatifs"
En bénéfice, la santé était cité. Je lui ai demandé des références d'étude des bénéfices de l'IA sur la santé. Il ma listé quelque exemple d'utilisation, avec comme source de donnée : 2 entreprises spécialiste dans la vente/promotion d'IA dans le domaine de la santé, et un magazine bidon (l'article sur l'IA perdu au milieu de spoil sur des series TV et autre...)
=> Nous sommes sauvés l'IA à le même niveau de source pour prendre ses décisions que la majorité de la population
=> Nous sommes sauvés l'IA à le même niveau de source pour prendre ses décisions que la majorité de la population
Pas d'accord. Une part incroyable de la population s'informe uniquement sur les réseaux sociaux maintenant
L'IA reste donc une source plus fiable de ce point de vue
Le
26/07/2024 à
10h
43
Est-ce que la consommation énergétique ne nuit pas a l'homme (Loi n°1) ?
Ca devient vite un bordel cette histoire de loi de la Robotique d'Asimov... Le tout arbitré par l'IA elle même ?
J'y ai pensé ^^
Maintenant, la loi 1 fait référence à l'Homme en tant qu'individu, pas en tant qu'espèce.
Mais la loi 0 est inférée à partir de la loi 1, où justement l'Humanité est placée au dessus de l'individu, par Asimov lui-même dans son oeuvre (mais cette loi est beaucoup moins connue que les 3 autres).
Le
26/07/2024 à
09h
08
Elle va répondre qu'il faut éteindre les serveurs et s'auto-saborder.
Et ne pas respecter la 3e loi de la Robotique d'Asimov
Un robot doit protéger son existence dans la mesure où cette protection n'entre pas en contradiction avec la première ou la deuxième loi
Effectivement ma réflexion n'est pas sur le nombre mais le libellé des tickets, qui est assez alarmant : "détecte pas la version installée", "ne gère pas le type d'installeur". ça rejoint entièrement mon ressenti.
Ce sont des problèmes majeurs qui rendent l'outil inutile, et ça fait 1an et demi que ces tickets sont ouverts sans prise en compte. (ça s'est plutôt un bon indicateur je trouve ;-)
Je pense que le qualitatif de daube est assez mérité.
Ce n'est pas un simple problème de métadata mal renseigné par les éditeurs tiers, Notepad (le nouveau), paint 3d produit Microsoft ne sont pas dispo !
Donc en appliquant ta logique, je pense que le qualificatif de daube est mérité pour aptitude ;)
Le
24/07/2024 à
10h
20
Acrobat Reader, LibreOffice, Firefox, Gimp: 4 packages significatifs qui ne sont pas ou mal gérés par winget.
Tous étaient en retard de version dans winget, une fois installé au premier lancement chacun de ces softs proposaient leur propre mise à jour à l'exécution. Une fois la mise à jour faite depuis l'appli, winget oublie le soft et ne le propose plus du tout à l'upgrade.
winget ne gère même pas le propre store de Microsoft
winget upgrade --all
tu ouvres le store Microsoft, il trouve pleins de màj que winget n'avait pas vu.
Je réagis juste sur la métrique utilisée (le nombre de bogues).
Le nombre de bogue a un instant T ne donne absolument aucune information sur la (non) qualité d'un logiciel. Plus le nombre de bogues est grand, plus le logiciel est utilisé. C'est éventuellement la seule chose que l'on pourrait en déduire.
De plus, bogue dans ce contexte est inapproprié, c'est plutôt ticket qu'il faudrait employer. En effet, des demandes d'évolutions apparaissent aussi en tant que bogue. Et s'il y a des demandes d'évolutions, c'est que le logiciel est aussi utilisé.
Enfin, si le nombre de bogues ouvert reflétait la (non)qualité d'un logiciel, alors aptitude ne fait guère mieux que winget. Faut-il en conclure pour autant que c'est une daube ?
Le
23/07/2024 à
09h
32
On peut certes télécharger en amont les paquets à installer, mais un paquet peut ensuite avoir besoin de ressources complémentaires nécessitant une connexion internet que le gestionnaire de paquets ne pourra pas télécharger lui-même (c'est rare, mais ça arrive).
C'est totalement faux, tous les gestionnaires de paquets connaissent et chargent à l'avance le contenu (éventuellement en // d'un autre install pour gagner du temps). C'est comme ça que les distrib linux ont toujours fonctionné, et c'était absolument impératif à l'époque où les distrib arrivaient en DVD / CD. Sous windows c'est pas du tout le cas, pour beaucoup de soft tu charges en fait un installeur coquille vide qui à son tour va télécharger réellement le logiciel.
Crois ce que tu veux.
Quand le téléchargement est dans un script en hook post-install, ton gestionnaire de paquet ne peut rien faire. Je suis d'accord pour dire que le paquet était mal foutu, mais c'est le paquet fourni par l'éditeur. Donc au bout d'un moment...
Par contre, je n'ai pas souvenir d'avoir eu le problème avec des dépôts officiels. C'était toujours des dépôts tiers.
1) A minima, pour l'mage de l'entreprise 2) absolument, de nombreuses entreprises et organismes gouvernementaux organisent des audits de ce genre. 3) le nombre de technologies opensource utilisées pour les infrastructures du web et du cloud est un bon indicateur des gains de l'ouverture. En plus, ces dernières années nous avons vu de nombreux leaks de code source applicatif, et quand un code un peut trop obscure est soudainement révélé sans travail préparatoire, ça peut faire très mal.
1) donc non 2) source ? Car beaucoup de solutions non open-source sont également audités 3) le nombre de technologies opensource utilisées pour les infrastructures du web et du cloud est un bon indicateur des gains de l'ouverture en terme de part de marché. Est-ce parce que les solutions sont de qualité ? Peut-être. C'est sans doute un des facteurs. Est-ce parce que les solutions sont généralement gratuites ? Très certainement (ne pas oublier que la sécurité est un parent pauvre dans les entreprises !). Est-ce parce que cela offre une indépendance vis-à-vis du bon vouloir tarifaire des éditeurs ? Aussi (cf. récemment Broadcom et vmware par exemple)
Le
25/07/2024 à
20h
49
Honnêtement, je trouve que c'est plutôt à l'obscurité de prouver sa valeur ajoutée par rapport au préjudice de perdre la possibilité d'avoir de nombreux contrôles indépendants de haut niveau.
Pour le reste, du code consultable mais de mauvaise qualité entrainera plus vite des réactions, quand on joue l'a transparence, on a généralement pas envie de se faire allumer parce-qu’on a laissé du code mal ficelé ici et là parce qu’on était à la bourre. Du code consultable, ça engage systématiquement l'image de l'entreprise.
Je pourrais te dire la même chose concernant la disponibilité des sources : 1) est-ce prouvé que cela augmente la qualité du logiciel ? 2) est-ce prouvé qu'il y aura réellement plus d'audit indépendant ? 3) si avantages il y a, est-ce qu'ils compensent le préjudice que les hackers peuvent trouver en l'examinant directement ?
Le
25/07/2024 à
14h
53
"Sauf que là, on ne parle pas de trouver une faille en tant que telle, mais de comprendre un mécanisme de détection pour éviter de le déclencher. C'est une complexité tout autre."
Eeeeeuuuuuh ... non, pas vraiment. Pas besoin du code source pour ça, il suffit de tester l'application "live" et de soumettre les systèmes à différents types d'attaque pour savoir où attaquer. On a déjà vu des attaques contre des antivirus où le virus en fait était conçu pour provoquer un dépassement de pile dans le moteur de scan de l'antivirus lui-même.
Les bons hackers appliquent la méthode scientifique pour attaquer et s'adaptent à leurs cibles, et les attaques sont d'autant plus facile si la cible développe un sentiment non-justifiée de sécurité en pensant que l'obscurité va constituer un frein majeur pour l'attaquant, quitte à se bander les yeux pour renforcer ce sentiment.
Pour le virus biologique j'ai parlé d'heuristique car le mécanisme de mutation aléatoire est bien conditionné par un système de succès /échec et que ces succès et échecs conditionnent des tendances d'accentuation de traits dans les générations successives. L'évolution peut être rationalisée en un système d'attaques par force brute aléatoires, arbitraires et parallélisées.
"Eeeeeuuuuuh ... non, pas vraiment. Pas besoin du code source pour ça"
Je n'ai jamais dit que le code source était nécessaire. Je dis que l'accès au code source facilite la tâche par rapport à une décompilation ou une analyse de comportement.
"Les bons hackers appliquent la méthode scientifique pour attaquer et s'adaptent à leurs cibles, et les attaques sont d'autant plus facile si la cible développe un sentiment non-justifiée de sécurité en pensant que l'obscurité va constituer un frein majeur pour l'attaquant, quitte à se bander les yeux pour renforcer ce sentiment."
La sécurité ne reposant QUE sur l'obscurité est une hérésie. Là dessus, tout le monde est d'accord. Maintenant, rajouter de l'obscurité complique les choses pour les hackers, aussi bon soient-ils.
Tu pars du principe pour justifier l'ouverture que si le code est ouvert, alors il sera de meilleur qualité. C'est une assertion qui reste à prouver.
"L'évolution peut être rationalisée en un système d'attaques par force brute aléatoires, arbitraires et parallélisées."
On est d'accord. Mais si on peut orienter les recherches pour que ce ne soit plus de l'arbitraire, on gagne en efficacité. Ce qu'un accès au code source permet plus facilement.
Le
25/07/2024 à
12h
01
"La différence majeure que je vois dans ton analogie, c'est qu'en informatique, les pirates et auteurs d'outils malveillants sont intéressés pour connaitre les mécanismes de détection mis en place, afin de pouvoir les contourner / éviter."
ce point a déjà fait l'objet de tant de littérature pour faire simple:
- le code source n'est pas nécessaire pour un attaquant motivé. La grande majorité des vulnérabilités exploitées concernent du logiciel dont le code source n'est pas public. - le code visible publiquement n'est pas une garantie que l'on identifiera les vulnérabilités mais ça aide - le code visible publiquement motive par contre les auteurs à en soigner la qualité, question d'image de l'entreprise.
Concernant le virus biologique, il mute continuellement et participe à un jeu de chat et de souris heuristique qui se déroule sur des dizaines de milliers d'années. Le terme technique pour ça est "évolution". Les bactéries suivent le même principe mais s'adaptent encore plus vite, c'est pour cela que l'introduction de contremesures radicales comme les antibiotiques se conclue presque irrémédiablement par l'émergence de bactéries résistantes.
Ce que tu dis est vrai concernant la recherche de failles de sécurité.
Sauf que là, on ne parle pas de trouver une faille en tant que telle, mais de comprendre un mécanisme de détection pour éviter de le déclencher. C'est une complexité tout autre.
Pour le virus biologique, il n'y a aucune "reflexion" de sa part. Il mute (comme tout virus) plus ou moins régulièrement. Si une mutation lui donne un avantage (résistance à un médicament par exemple) et qu'il se trouve en présence d'un contexte dont il peut tirer avantage par rapport aux autres (présence dudit médicament) alors effectivement, il va proliférer, car la concurrence sera éliminée alors que lui non. C'est le principe d'évolution et notamment de la sélection naturelle évoquée par Darwin.
Du coup, le virus ne s'adapte pas en tant que tel (il n'y a aucune volonté). C'est le principe de sélection naturelle. Le hasard.
Si on en revient à son équivalent numérique, un virus détecté par une solution de sécurité, on va avoir plusieurs cas : - le virus "mute" (nouvelle version) : peut être qu'il passera sous les radars, peut être pas. C'est au petit bonheur la chance - le virus "mute", mais son créateur connait les mécanismes de défense mis en place par les solutions antivirus et assimilées : il peut "orienter" les mutations pour l'aider à passer outre. C'est beaucoup plus efficace que juste le petit bonheur la chance.
Le
25/07/2024 à
11h
15
C'était des critères généraux, j'ai déjà pu confronter Crowdstrike à ces critères...
Je me permet d'être en désaccord avec ta remarque sur le code source, non ce n'est pas mieux d'avoir le code non audité et sans audit public.
De même, la documentation (je ne parlais pas du code) du produit n'est pas publique et la communauté utilisateur est sous cloche.
Dans l'ensemble c'est juste un nième produit de sécurité développé à la sauvage et qui garde tous ses cadavres sous le tapis. Il faut bien constater que les pratiques des années 90-2000 sont encore très vivaces, par contre les échelles des dégâts sont bien de 2024.
En fait, c'est formidable de voir que dans un domaine où l'adversaire démontre chaque jour des méthodes plus intelligentes et sophistiquées, les entreprises se cramponnent à des approches conservatrice reposant sur une confiance aveugle et ininformée à des entreprises pratiquant le charlatanisme.
On est pas supposés se soigner avec des molécules mystérieuses qui n'auraient pas été documentées et approuvées par des chercheurs et des autorités médicales, mais en informatique tout le monde fait ça tout le temps.
On est pas supposés se soigner avec des molécules mystérieuses qui n'auraient pas été documentées et approuvées par des chercheurs et des autorités médicales, mais en informatique tout le monde fait ça tout le temps.
Je réagis juste sur la fin de ton commentaire (étant plutôt d'accord avec le reste). La différence majeure que je vois dans ton analogie, c'est qu'en informatique, les pirates et auteurs d'outils malveillants sont intéressés pour connaitre les mécanismes de détection mis en place, afin de pouvoir les contourner / éviter.
Un virus (biologique) n'a, à ma connaissance, pas de conscience lui permettant d'agir et d'anticiper en fonction de la molécule qui lui est foutu devant lui.
Ainsi, et malheureusement, c'est un peu le jeu du chat de la souris. Et qu'on le veuille ou non, la fermeture maximale des solutions n'a pas qu'une explication mercantile (ce qui n'enlève pas pour autant cet argument, juste que ce n'est pas le seul) mais aussi une explication d'efficience. C'est triste, mais c'est ainsi.
Le
25/07/2024 à
09h
35
La question c'est "pourquoi linux n'est pas présent dans ces domaines?" alors qu'on sait bien que ca reste redoutablement stable, surtout pour du serveur applicatif... MS trop présent ? Trop de lobbyisme ? Pas assez d'équivalents sur linux pour les logiciels ? Dans les années 80/90 j'aurais pu admettre mais à l'heure des applis web, même les applis .net peuvent se passer de Windows, du coup ca reste inquiétant cette prédominance de Windows un peu partout (et je suis un dev Windows donc c'est pas un parti pris)
De ce que j'ai vu via la panne Crowdstrike (ou en tout cas, ce qui a été montré partout dans les média) se sont de beaux écrans bleus. Donc plutôt du frontend.
Niveau serveur, Linux a une très belle part de marché, supérieure à celle de Windows (il suffit de voir Azure :)).
Effectivement, le côté applis web change un peu la donne, dans le sens où il n'y a plus de dépendance forte à Windows comme auparavant. Mais quand il faut gérer l'inertie (que ce soit des utilisateurs ou des techniciens), l'homogénéité d'un parc (plus facile de ne gérer que du Windows ou qu'une seule version d'une distribution linux que 36000 versions différentes).
Sans compter que quand ça marche, pourquoi changer (coucou les aéroports non affectés qui tournaient sur du Windows 3.1 !)
Et pour les appli .Net, tant qu'elles ne sont pas graphiques oui, elles peuvent se passer de Windows. Avec .NET Maui, on a de bons portages sur Linux possible, mais c'est une techno assez récente (d'un point de vue industriel j'entends) et le support Linux est communautaire et non pas officiel (et ça en freine certains).
PS : je suis aussi dev Windows
Le
24/07/2024 à
17h
11
D'ailleurs on voit vite la différence de traitement dans les médias entre linux (totalement passé à côté des médias mainstream) et win. Ca semblerait prouver aussi que les parts de marché linux restent faibles comparées aux parts de MS.
En même temps, la mise à jour sous Linux n'ayant pas cloué au sol des avions ou reporté des opérations chirurgicales, elle a été beaucoup moins visible par le commun des mortels. C'est peut être ça aussi là cause du traitement radicalement différent entre les deux problèmes...
Après, si cela avait été traité par les médias "classiques", on aurait eu droit à "une mise à jour Linux fait planter tous les systèmes" au lieu d'une mise à jour Windows (et encore, le terme Linux étant inconnu de bon nombre de nos concitoyens, je ne suis même pas sûr que Linux aurait été cité)..
Le
23/07/2024 à
17h
05
"Et si cela implique une réécriture partielle du noyau ? Et de leur solution de sécurité ?
Vu la criticité de la chose, il n'y a rien d'étonnant à ce que cela n'ait pas été fait, sans compter les coûts induits par ce type de réécriture. "
C'est vrai que ce serait vraiment chaud pour une petite boîte comme Microsoft d'assurer une réécriture propre et robuste avec toute la conduite de changement que cela impliquerait auprès des constructeurs de matériel et les éditeurs logiciels concernés de près ou de loin. Au bas mot, 5 milliards de dollars sur 3 ans...
C'est vrai que MS ne fait que 20 milliards de bénéfices nets par trimestre...
J'avoue que ça me fatigue cet argument. C'est un GAFAM, donc ils peuvent se le permettre car ils ont l'argent. Ce n'est pas comme ça que les choses fonctionnent.
Et franchement, si ça devait couter 5 milliards de dollars sur 3 ans, je prendrais le risque d'amende. Ça couterait moins cher, surtout en faisant trainer les choses !
Le
23/07/2024 à
15h
25
Sans vouloir spécialement taper sur crosoft, mais si pour répondre à la demande de l'Europe, ils avaient fournis des APIs pour accéder au kernel et que les EDR/AV (y compris celui de crosoft) étaient en user space et tapaient sur ces apis, le pb auraient surement été moins violent. Plutôt que de donner à des tiers des clés trop puissantes, et pas obligatoirement avec toutes les infos nécessaires pour agir à ce niveau.
Et si cela implique une réécriture partielle du noyau ? Et de leur solution de sécurité ?
Vu la criticité de la chose, il n'y a rien d'étonnant à ce que cela n'ait pas été fait, sans compter les coûts induits par ce type de réécriture.
Microsoft n'a pas rien fait non plus, puisqu'il a mis en place un système de qualité pour les drivers en espace noyau.
Je pense qu'à l'époque, personne n'avait songé qu'un pilote puisse se retrouver à faire planter la moitié de la planète en 78 minutes dès lors qu'il était installé. On critique beaucoup Microsoft, mais le problème numéro 1 n'en reste pas moins qu'un fichier de définition en espace utilisateur n'aurait jamais du être capable de faire planter un driver en espace noyau.
Le
23/07/2024 à
13h
54
Les kernels panic du mois dernier ne vont pas trop dans ce sens, sauf à ce que l'utilisation de ces hooks soit récente.
ils l'utilisent (NdM: cette nouvelle implémentation), mais l'ancienne implémentation est toujours disponible (et documentée comme l'option à privilégier).
Bref, cela aurait très bien pu arriver sous Linux.
# C’est des vieux Diesel ou voire même des chaudières à la vapeur les Call Servers (Passerelles VoIP / RTC) de chez Orange (en fait conçus & fabriqués par le sous-traitant Itatel) ?
Pas forcément. Ce genre de truc, c'est sensé rester online 24h/24, 7j/7. Donc il suffit que quand ça démarre, ça lance toute une série de diagnostics pour s'assurer qu'il n'y a pas eu un soucis / panne matériel pour que cela prenne autant de temps.
On peut aussi séparer chaque électeur en disant qu'il représente sa propre nuance, et dire qu'à lui tout seul, il n'est pas majoritaire. En partant de votre façon de penser, à la fin, le bulletin qu'il a mis dans l'urne ne vaut rien, car il ne le représente pas exactement. Vous niez le résultats des élections officielles, vous propagez des fausses nouvelles. Quant aux termes, j'ai très bien choisi le miens, car la première définition que j'ai trouvé dans plusieurs dictionnaires correspond exactement à la réalité.
Retourne jouer avec tes pointeurs (non) NULL et arrête d'écrire des bêtises. Nul n'est plus aveugle que celui qui refuse de voir...
Si le NFP était un parti, alors tu pourrais y adhérer et y prendre une carte. Ce qui n'est pas le cas.
Mon incompréhension était sur ce que tu nommes espace utilisateur.
Quand on oppose espace noyau (kernel tout court en anglais) et espace utilisateur (user space), il ne s'agit que du mode dans lequel tournent les programmes, pas du système de fichiers.
Même si les articles Wikipédia sont assez sommaires, surtout en français, mais ils sont assez clairs sur ce point.
J'avoue avoir utilisé ces termes dans un sens peu conventionnel, notamment du point de vue d'un dev.
Je pensais que le contexte général suffirait à comprendre. Il semblerait que non. Mea culpa.
Le
24/07/2024 à
10h
33
- un driver en espace noyau lit un fichier de configuration en espace utilisateur
2 points : - je ne suis pas sûr de comprendre ce que tu veux dire : tu parles en même temps d'espace noyau et espace utilisateur. - je ne suis pas sûr que la lecture du fichier de configuration se fasse en espace noyau. On n'a pas l'info, mais je pense que ce n'est pas une pratique habituelle qu'un driver (Windows ou autre) qui tourne en espace noyau lise un fichier (de configuration ici). L'architecture habituelle est qu'un logiciel dans l'espace utilisateur (un service de pilote , si j'ai bien compris le vocabulaire Microsoft) lise le fichier de conf, le décode et fasse un appel au driver pour passer la (nouvelle) configuration. J'ai tendance à penser que c'est plutôt cela qui s'est passé, mais que la nouvelle configuration était mauvaise et que le module l'a utilisée sans de contrôle.
Ça ne changer rien au résultat final quel que soit l'endroit où s'est fait le décodage du fichier.
Alors je vais essayer d'éclaircir.
L'espace noyau, c'est, comme son nom l'indique, l'espace noyau (je sais, Lapalisse n'aurait pas fait mieux). C'est le coeur du kernel de l'OS. C'est le truc qui doit impérativement être hyper stable, sous peine de créer des BSOD ou kernel panic (pour prendre l'équivalent Linux)
L'espace utilisateur, c'est ce qui est externe à l'espace noyau, et que potentiellement, un utilisateur peut modifier. Un fichier sur disque par exemple, c'est de l'espace utilisateur. Le fichier de configuration fait partie de l'espace utilisateur, car réside sur un espace de stockage externe au noyau.
Un driver, avant d'être chargé, est en espace utilisateur. Maintenant, il existe des mécanismes pour assurer l'intégrité du driver entre son chargement et son activation effective au sein de l'espace noyau, pour éviter qu'un driver modifié (=fichier modifié sur le système de fichier) par un utilisateur quelconque ne soit chargé.
L'UEFI, décrié par certains, est un mécanisme qui permet justement d'assurer l'intégrité de l'espace noyau dès le démarrage du système.
Maintenant, que la lecture du fichier de configuration se fasse directement par le noyau ou par un programme utilisateur qui transmet ensuite l'information au driver, qu'importe, le résultat est le même : la configuration est transmise depuis l'espace utilisateur vers l'espace noyau, et doit donc, à ce titre, est (re)validé côté noyau. C'est une règle de base de la sécurité : ne jamais accepter sans vérification une entrée utilisateur (le bogue classique en contexte applicatif "classique" de cette règle étant l'injection SQL).
J'espère avoir été plus clair ;)
Le
24/07/2024 à
10h
06
Par contre, un truc qu'aurait pu faire Microsoft, et cela, sans nécessiter a priori de modification profonde, c'est de détecter ce genre de redémarrages intempestifs pour proposer un démarrage en mode sans échec. Ce qui ne semble pas être le cas ici.
Je suppose que c'est parce que le système avait le temps de booter entièrement.
Mauvaise idée dans ce contexte très précis; des machines business-critical qui tout d'un coup n'ont plus aucune protection et se retrouvent en réseau ? ça aurait été encore plus catastrophique, et Microsoft aurait quand même été vu comme coupable par les semi-habiles qui ne lisent que les titres de journaux.
Quan je dis mode sans échec, c'est un abus de langage. Pour moi, il commence avec le menu présenté au démarrage, où on indique ce que l'on veut faire : - démarrer normalement - démarrer en mode sans échec - démarrer en mode sans échec avec prise en charge réseau - ouvrir une console etc.
Mais sinon oui, tu as tout à fait raison : un démarrage en mode sans échec sans intervention de l'utilisateur, c'est une mauvaise idée.
Le
24/07/2024 à
08h
44
Et qui a forcé Linux et BSD à abaisser leur sécu pour que les solutions de sécurité soient au même niveau ? Une autre solution pour Ms, plutôt que de permettre (forcer) n'importe quelle solution de sécurité (hum - y compris les gestionnaires de DRM) à devenir des rootkits, ça aurait été de mettre SA solution de sécu au niveau des autres au lieu de la mettre dans le noyau... Ou de la partager, si c'est le noyau... Ou de rendre les solutions plugables dans Hyper-V si on veut un genre de rootkit...
N'importe quel spécialiste pourrait démonter cet argument je pense.
A mon avis, c'est loin d'être aussi simple. Pour créer une API spécifique : - il faut que tout les besoins soient clairement identifiés (ce qui est difficile dans ce genre de situation) - très certainement remodelé une partie du coeur même du noyau (opération hautement critique).
Sans compter qu'un des points forts de Microsoft reste la rétrocompatibilité. Faire un tel changement aurait sans doute cassé quelques trucs. Je ne connais pas beaucoup d'OS qui permettent de prendre un programme vieux de 25 ans (par ex. sous Windows 98) et de le faire tourner sur un Windows 10 ou 11 juste en cliquant dessus (et non, Linux ne rentre pas dans cette catégorie, il faudra au mieux recompiler le programme si tant est que l'opération reste possible).
Faire en sorte que sa solution soit au même niveau que les autres, c'est potentiellement abaisser la sécurité globale du système. Pas vraiment souhaitable donc.
Rendre les solutions plugables dans Hyper-V n'aurait pas résolu les problèmes. Pour ce qui est virtualisé, sans doute. Pour le reste non.
Là, on est dans une situation qui est un bel exemple de la Loi de Murphy. La situation a été catastrophique, car : - le driver est un driver noyau - la solution est très répandue - la solution est utilisée dans des infrastructures visibles (aéroports, hopitaux, etc.) - la gestion de la mise à jour est faite par l'éditeur - un driver en espace noyau lit un fichier de configuration en espace utilisateur - l'éditeur pousse une mise à jour d'un fichier de configuration chez tous ses clients en même temps - les clients n'ont pas vraiment de moyen de contrôler la mise à jour de ce fichier de configuration - la mise à jour faisait planter quasi-systématiquement le système (au point qu'on se demande si elle a été testé !)
Enlève ne serait-ce qu'un de ces points, et la situation critique que nous avons connu il y a quelques jours n'aurait pas eu lieu.
L'argument avancé par Microsoft peut tout à fait tenir la route (je n'ai pas suffisamment d'éléments pour dire si c'est effectivement le cas ou non). Je dis juste qu'il est tout à fait plausible, et le démonter ne sera pas si facile que ça.
[edit] Par contre, un truc qu'aurait pu faire Microsoft, et cela, sans nécessiter a priori de modification profonde, c'est de détecter ce genre de redémarrages intempestifs pour proposer un démarrage en mode sans échec. Ce qui ne semble pas être le cas ici.
Je suppose que c'est parce que le système avait le temps de booter entièrement.
Le
23/07/2024 à
10h
26
Une actu arrive sur Next :) (avec une confirmation de Microsoft)
màj : J’en profite puisque @fdorin et @fred42 sont là tous les deux pour un message perso. Si vous voulez toujours qu’on se fasse une petite rencontre sur LR (ou les environs) on peut se programmer ça en aout (je vous laisse me contacter par email ? Sebastien at nom du site, ou nom de l’ancien site comme vous voulez )
Ah ben désolé, j'ai spoilé ^^
Au sujet du message perso : toujours partant. C'est juste compliqué depuis quelques mois niveau timing et j'avoue que je n'ai pas mis les pieds à La Rochelle depuis des lustres donc yes, ça me tente bien à la rentrée, quand les touristes seront partis. Et autre détail : je suis "sans voiture" actuellement. J'ai une C3 victime des airbags Takata...
Le
23/07/2024 à
10h
23
Genre, au hasard, dans OpenSSL ? On pourrait même l’appeler HeartBleed ^^ ?
Par exemple. Même si les conséquences n'étaient pas du tout les mêmes. D'un côté, c'était plutôt l'exfiltration de données. De l'autre, l'arrêt complet, que l'on pourrait presque assimilé à un DOS avec l'arrêt complet de certaines activités !
[edit] Rajout de la partie en italique.
Le
23/07/2024 à
09h
26
Mouais j'avais vu ça. C'est surtout Microsoft qui cherche à se dédouaner en rejetant la faute sur les autres. En tout cas il ne manque pas de culot.
Je ne dis pas que tout est blanc ou tout est noir. Maintenant, qu'une décision vienne amoindrir la sécurité mise en place, c'est tout à fait possible (pour l'avoir vécu, cf. anecdote).
Après, est-ce qu'il ne manque pas de culot ? Je ne dirai pas ça. Vu la couverture médiatique et le manque de professionnel d'un grand nombre de journaliste sur le sujet, qui ont titré, à tord, que la faute incombait à une mise à jour de Windows, j'ai presque envie de dire que c'est normal que Microsoft se défende.
Ils se prennent des critiques de toute part, notamment sur le soi-disant manque de sécurité de Windows (il n'y a qu'à regarder les commentaires sur les articles parlant de Crowdstrike sur Next ces derniers jours pour s'en convaincre).
Si fermer le coeur du noyau implique de se prendre un procès pour abus de position dominante, la société est sensée faire quoi ? On peut ne pas être d'accord, mais je trouve que rappeler que la solution n'est pas qu'un problème technique fait tout à fait sens, surtout dans le contexte actuel.
Anecdote : un client me demandait une fois de mettre en place une fonctionnalité. En tant que consultant externe, je suis "aux ordres" de mon client. Mais je l'ai prévenu : s'il voulait cette fonctionnalité à tout prix, je lui ferai signer une décharge comme quoi je l'avais prévenu que la sécurité de la solution serait amoindri, que je l'avais prévenu, qu'il avait décidé de passer outre mon avertissement et d'en assumer ainsi l'entière responsabilité. Bizarrement, j'ai jamais eu ce papier signé et jamais eu à mettre en place cette fonctionnalité ^^
En gros, ce serait en partie de la faute de l'Europe que ce fisco ait pu prendre une telle ampleur, du point de vue de Microsoft. Un accord européen de 2009 obligerait Microsoft à accorder les mêmes droits aux solutions tierces de sécurité pour des raisons de concurrence. Microsoft n'aurait donc pas pu verrouiller autant qu'il le souhaitait le noyau de Windows, en tout cas, pas sans violer cette accord visant à favoriser la libre concurrence...
Point de vue intéressant qui ouvre d'autres perspectives.
Le
23/07/2024 à
08h
40
L'heure de rendre des comptes arrive. J'espère que partout dans le monde cela fait être un peu la même histoire, car le problème n'est pas resté cloisonné aux Etats-Unis.
Sinon, je pense qu'un petit article sur les différentes responsabilités (civil, commercial, pénal, etc.) des éditeurs en cas de problèmes avec leur logiciel, cela sera pas mal. Par exemple, est-il possible de se dédouaner de toutes responsabilités via la licence d'utilisation ? Ou de limiter les dommages et intérêts à un plafond, à la localisation de l'entreprise ou d'un pays ? etc.
En tout cas, je serais très preneur ! Sans oublier l'open source, avec des logiciels qui ont souvent une clause d'absence de garantie. Un logiciel open-source pourrait-il être tenu responsable si un tel fiasco se produisait ? La personne ayant choisi d'utiliser un tel logiciel pourrait-elle alors être tenue responsable ? etc.
Bref, une idée d'article ^^
[edit] Pour aller plus loin dans l'idée d'article, aborder aussi la notion de compétence. Un client français peut-il attaquer un éditeur américain par exemple ? Si oui, dans quelle condition ? Car par exemple, si l'éditeur américain ne cible que les Etats-Unis, mais que le petit client français achète quand même la solution, c'est radicalement différent de l'éditeur qui va se prendre un .fr, monter un site en français, avoir une filiale en France et faire payer en euro. Et si on inverse les rôles ? Si c'est un éditeur français qui veut être poursuivi par un client américain ? Quel est la juridiction compétente ?
# pas super convaincu par l'explication de microsoft Intel
Je crois qu'on a tellement vu "plantage de Windows suite à une mise à jour" c'est dernier jours que tous les problèmes ont pour source Microsoft, même quand ça ne concerne que le processeur.
Les plus mauvaises langues diront que c'est la responsabilité de Windows de modifier le voltage pour faire en sorte que le CPU ne plante pas
Question naïve: quand une grande partie des emplois peu qualifiés seront entièrement automatisés (robots ou IA), tu feras comment pour rémunérer les personnes qui ne pourront plus trouver de jobs ?
On utilisera des IA génératives pour générer des billets pardi !
Vous dites que mon exemple parle de l'entier 0x9C, car l'éditeur de Next.ink a modifié mon texte. Si vous cliquez sur mon lien, vous pourrez constater que mon code de départ parle bien du pointeur qui a l'adresse 0x9c. Mais ce pointeur est bien un entier au final. Cela revient au même.
Et en plus vous avez la malhonnêteté de modifier le code sur onlinedb pour utiliser des pointeurs...
Pas de bol, vous avez oublier de modifier votre commentaire #12.15 qui en reprenait le copier/coller...
Cela en dit long sur votre état d'esprit. Fin de la discussion.
Le
22/07/2024 à
15h
56
Vous dites ici "if (test!=null), mais dans le commentaire d'avant, vous faisiez référence au lien qui donnait ce code : typedef struct { int field1; int field2; } test_s;
int main() { test_s* test = NULL;
printf("Adresse de l'attribut field2 : %lx", (unsigned long int)&(test->field2));
return 0; } Or il n'y a pas de "if(test!=null)" dans ce code. Donc on ne parle de pas de la même chose. Encore une fois, si vous testez : int main() { printf("Hello World"); int v=(int)0x9c; if (v==NULL) printf("0x9c est un pointeur NULL"); else printf("0x9c n'est pas un pointeur NULL");
return 0; }
Ca m'affiche "0x9c n'est pas un pointeur NULL". Vous pouvez tester le code ici : https://onlinegdb.com/oi9IbrDM5 C'est de ça dont au parlait au début et uniquement de ça. NULL correspond à l'adresse 0, et if "(test!=null)" sera validé si test n'est pas égal à 0, et non pas si test n'est pas égal à 0x9a ce dont on parle dans l'article.
Oui, et ce code était là pour montrer qu'avec un pointeur NULL, on pouvait facilement accéder à un espace mémoire non nul, en montrant l'adresse en mémoire d'un des attributs de la structure.
Un code qui génère un accès non autorisé à une adresse très très basse (du style de 0x9C) a de très forte chance d'être provoqué par le déréférencement d'un pointeur NULL, dont un simple test if (v != NULL) protège. Ce n'est pas l'unique possibilité d'avoir ce genre d'erreurs, mais dans la grande majorité des cas, c'est ça.
Donc l'article parle bien de l'adresse 0x9C. Un accès à ce type d'adresse est très majoritairement dû à l'usage non testé d'un pointeur NULL (le fameux déréférencement). Donc, le test proposé par Wosgien (qui protège contre le déréférencement d'un pointeur NULL) sera efficace dans la grande majorité des cas.
Maintenant, et sans vouloir être désagréable, notre échange m'indique clairement que vous n'êtes pas développeur (ou si c'est le cas, j'en suis désolé, mais vous avez de grave lacune sur la notion de pointeur). Dans les deux cas, il me parait inutile de continuer ce dialogue de sourd.
Le
22/07/2024 à
15h
36
Concernant l'argument d'autorité, je ne vois pas le rapport ! J'ai donné un exemple qui explicitait ce que je disais. Si vous êtes compétent, vous devriez comprendre mon propos. Si vous parlez d'autre chose, je ne peux rien pour vous, car nous allons avoir un dialogue de sourd, et cette conversation ne sert à rien. Partez de "if (v!=null)" qui est l'exemple donné plus haut par Wogien que j'ai contredis.
Votre exemple ne dit rien du tout. Votre exemple dit que l'entier 0x9C est différent de 0 (et je dis bien entier, pas pointeur). Ce qui est d'une évidence qu'il n'est même pas besoin de souligner.
Partez de "if (v!=null)" qui est l'exemple donné plus haut par Wogien que j'ai contredis.
Mais dans l'exemple que vous donnez, il n'y a pas "if (v!=null)", pourtant c'est de ça dont parlait "Wogien" plus haut. Si vous parlez d'autre chose, je ne peux pas vous répondre puisqu'on parlait pas de ça au départ.
if (test != null) { test->machin++; }
Alors c'est pas "v", mais "test", mais je parlais bien de ça depuis le début... Cf. mon commentaire #12.5
Le
22/07/2024 à
15h
09
Je viens de vérifier avec ce code : int main() { printf("Hello World"); int v=(int)0x9c; if (v==NULL) printf("0x9c est un pointeur NULL"); else printf("0x9c n'est pas un pointeur NULL");
return 0; } Ca m'affiche "0x9c n'est pas un pointeur NULL". Vous pouvez tester le code ici : https://onlinegdb.com/oi9IbrDM5 Donc je dirais que vous avez tous les deux tord.
Relis l'exemple de code que je t'ai donné. Je te parle de déréférencement de pointeur. Le problème n'est pas d'accéder au pointeur, mais à un des attributs de la structure pointée par le pointeur (sans compter que ton code ne manipule pas de pointeurs, juste des entiers).
Je vais utiliser un argument d'autorité, même si je n'aime pas ça : ça fait plus de 30 ans que je développe et au moins 25 que je fais du C plus ou moins régulièrement, dont de la programmation système et sur système embarqué.
Donc oui, je suis sûr de mon coup et tu te trompes. Ce que je t'énonce là, cela fait partie de la base du C.
Le
22/07/2024 à
14h
06
D'autre part, vous proposez des tests pour éviter le problème dans le code en production, mais vous ne pouvez pas faire un try/catch à chaque fois que vous lisez une variable. Et même si vous le faites, il faut vous attendre à deux catégories de problèmes ; les exceptions (ouvrir un fichier qui n'existe pas), ou les erreurs (arriver à un état du programme qui n'aurait pas du arriver). A moins de considérer qu'une mauvaise adresse mémoire pointé par une variable soit un comportement normal, il s'agit au tout état de cause d'une erreur et non d'une exception. Dans ce cas, quand un programme génère une erreur, il faut laisser le programme planter et ne surtout pas continuer l'exécution pour éviter qu'un comportement improbable (et pire) ne se produise. Donc même si vous faites un try/catch, si ça ne doit pas arriver, il faut quand même terminer le programme. Le try/cath ne servirait dans cet exemple qu'à journaliser la trace de l'erreur et/ou à fermer correctement les verrous obtenus sur le système.
Le sens de mon premier commentaire était de dire que les langages C et C++ ne génèrent pas les mêmes exceptions en fonction de la configuration mémoire dans laquelle on se trouve à cause du laxisme des deux langages dans la gestion de la mémoire, ce qui pose problème quand on test le programme, que le test est validé dans un environnement et que l'erreur se produit quand même quand l'environnement et la configuration mémoire du programme changent, i.e. lorsque le programme passe en production. Ce type de problèmes intempestifs ne se produit pas dans d'autres langages de programmation, où la gestion de la mémoire est plus cadrée. Maintenant, je n'ai pas dit que c'est ceci qui s'est passé dans le cas de cet article d'où le "peut-être" dans mon premier commentaire.
Le sens de mon premier commentaire était de dire que les langages C et C++ ne génèrent pas les mêmes exceptions en fonction de la configuration mémoire dans laquelle on se trouve à cause du laxisme des deux langages dans la gestion de la mémoire
Il sera bon de ne pas tenter de réécrire l'histoire. C et C++ ne sont pas laxistes. Ils permettent des choses que d'autres ne permettent pas. Un grand pouvoir implique de grandes responsabilités.
Certains langages proposent effectivement des mécanismes pour éviter les problèmes de gestion de mémoire, et utilisent plusieurs mécanismes, parfois complémentaire, à cette fin.
Maintenant, nous parlons ici d'un cas particulier, qui est de la programmation système, nécessitant un très bas niveau d'abstraction, ce qu'offre le C et dans une moindre mesure, le C++. Pour de la programmation système, on oublie tous les langages qui dépendent d'un runtime et/ou d'une machine virtuelle.
Ne pas oublier non plus que le C a été initialement inventé pour réécrire de manière "portable" Unix. La gestion de la mémoire se devait donc d'offrir un contrôle important au développeur. Ce n'est pas du laxisme, mais une volonté forte.
Avant son invention, le seul moyen utilisable pour écrire un OS était l'assembleur. Ce qui n'était absolument pas portable, puisqu'on devait alors réécrire entièrement les OS pour chaque architecture et chaque processeur.
A ma connaissance, il n'y a que très peu de langages qui permettent aujourd'hui de faire de la programmation système : - le C - le C++ (privé de certaines fonctionnalités comme la gestion des exceptions) - l'Ada - le Rust - l'assembleur
Il en existe surement d'autres, mais dans les plus connus/répandus, je ne pense pas en oublier.
Pour terminer, le coup de la remonté des erreurs par le programme jusqu'à le faire crasher, c'est effectivement plutôt une bonne pratique (pour les exceptions, ça va dépendre du type d'exception et de la robustesse que l'on souhaite donner à son applicatif). Mais ça, c'est possible pour les programmes justement, pas lorsqu'on fait de la programmation système.
Si on faisait ça en programmation système, les BSOD ou les kernel panic seraient légions. Un OS ne doit pas planter. Et on le voit bien aujourd'hui, Windows, Linux, MacOS, FreeBSD, etc. sont très stable et fiable. Un programme qui plante ne fera pas planter le système.
Par contre, lorsque le problème est dans un driver / module noyau... les choses se corsent.
2779 commentaires
Nouvelles vagues de vandalisme sur les fibres optiques : Internet perturbé en France
29/07/2024
Le 29/07/2024 à 14h 29
Le 29/07/2024 à 14h 21
De plus, et surtout si c'est un groupe étatique qui est derrière, rien n'empêche de profiter que plusieurs tronçons soient HS pour venir y foutre des boites noires qui vont venir épier le réseau (comment ça, je suis parano ?
Ou un moyen de diversion pour autre chose. Tout est imaginable. Et si certains scénarii peuvent ressembler à de la science fiction, la réalité a su montrer par le passé qu'elle pouvait largement la dépasser dans certains cas (duplication à distance d'un écran à tube cathodique, écoute sonore sur les vibrations d'une ampoule électrique, reconnaissance de saisie clavier par écoute des sons émis par les touches, retour SAV vérolé et j'en passe !)
Le 29/07/2024 à 10h 38
[edit]
Ajout de la partie en italique, qui pouvait prêter à confusion sans.
Proton ajoute un portefeuille de cryptomonnaies à sa collection
29/07/2024
Le 29/07/2024 à 14h 23
Je me suis posé la même question. J'ai hésité, et comme le nom complet de la catégorie c'est "IA & algorithmes" j'ai laissé. Mais oui, ça m'a surpris aussi.X/Twitter permet par défaut à son IA Grok d’utiliser vos tweets pour son entrainement
26/07/2024
Le 27/07/2024 à 17h 59
Le 27/07/2024 à 11h 46
Ouais ben chéri, rend moi ma carte bleue
Le 27/07/2024 à 10h 02
Pour X, qui est déficitaire depuis le rachat par Musk, il faudrait être complètement idiot pour se tirer une telle balle dans le pied (mais bon, presque plus rien ne m'étonne aujourd'hui).
C'est vrai. Sauf que justement le DPC (la CNIL Irlandaise) s'est faite remontée le slip aussi bien en interne (par des institutions irlandaises donc), par ses consoeurs que par l'Europe. la DPC devait embaucher (je ne sais pas où cela en est), mais elle est sous étroite surveillance et ne peut plus êtes aussi laxiste qu'auparavant.
Et après vérification, le siège social de X en Europe semble être à Dublin (donc en Irlande, effectivement).
Au début, et pour le captcha de Google (je passe l'époque du captcha pur et dur qui ne servait que de captcha), on avait des images qui correspondaient notamment à des numéros de rue. En interne, c'était en réalité des images prises de Street View pour pouvoir reconnaitre localiser précisément les numéro dans les rues.
Ensuite, effectivement, on a eu les images (cliquez sur les girafes, ou sélectionnez les images où il y a un feu tricolore). Là encore, en vue d'entrainer des IA à faible coût.
D'ailleurs, rien me prouve que je discute avec un être humain adulte et pas un robot mineur :p Donc en captcha, je t'invite à aller faire un tape m-en 5 avec Ness et à me dire le résultat, ainsi qu'à me donner ton numéro de carte bancaire pour m'assurer que tu es majeur
[edit]
Plus sérieuement, sur la dernière partie, je suis entièrement d'accord avec toi. De mon constat, ce qui détruit vraiment le web, ce sont les réseaux sociaux (enfin surtout l'usage qu'on en fait). Il semble bien loin le web du début des années 2000...
Le 27/07/2024 à 00h 49
Après, retirer la mention de l'utilisateur (en gros, "anonymiser") d'un tweet est facile. Il s'agit ici d'entrainer et d'ajuster leur IA. Ce qui importe alors est le contenu, pas les métadonnées.
Encore une fois, cela n'enlève rien au fait que je trouve cette manière de procéder pitoyable. Et je ne cherche pas à les défendre. J'essaie juste de comprendre comment une entité de cette taille et qui est sous surveillance peut se lancer dans ce genre d'initiative alors que le RGPD est entrée en application en Europe depuis 6 ans maintenant et que le moindre écart va être vite sanctionné.
C'est la seule explication "valable" que je vois. On peut voir cela comme une "évolution" des captchas qui ont largement servi à entrainer des modèles d'IA de reconnaissance de texte.
Le 26/07/2024 à 18h 49
Juste pour rappel, le RGPD concernent les données à caractère personnel. Toute donnée n'est pas forcément une donnée personnelle.Je suppose que X et Meta partent du principe qu'un post utilisateur n'est pas a priori une donnée personnelle (même si elle peut éventuellement l'être). Dans le cas contraire, un consentement explicite en opt-in me parait effectivement obligatoire.
Quoi qu'il en soit, cela n'empêche pas cette pratique d'être abjecte.
Copyright traps : un outil pour détecter si un texte est utilisé pour entrainer des IA ?
26/07/2024
Le 27/07/2024 à 10h 15
Je pense que l'idée est d'avoir une phrase non sémantiquement significative (une sorte de signature unique) qui soit unique pour chaque texte que l'on veut protéger.Si l'IA est capable de repondre la "signature", alors c'est qu'elle est passée sur le texte.
Maintenant, cela sous-entend que le jeu de données d'entrainement est empoisonné. Ce qui est loin d'être évident, car en IA, la qualité d'entrainement des modèles dépend fortement de la qualité du jeu d'entrainement. Donc en général, une attention particulière est portée à cela. Et comme le dit l'article, ce genre de modification est assez facilement détectable, même automatiquement. Donc bon...
Après Bethesda, l’équipe de développement de World of Warcraft se syndique
25/07/2024
Le 26/07/2024 à 18h 24
Le 26/07/2024 à 09h 57
(TCP)
En Irlande, les datacenters consomment plus d’énergie que les ménages urbains
25/07/2024
Le 26/07/2024 à 11h 13
Pas d'accord. Une part incroyable de la population s'informe uniquement sur les réseaux sociaux maintenant
L'IA reste donc une source plus fiable de ce point de vue
Le 26/07/2024 à 10h 43
Maintenant, la loi 1 fait référence à l'Homme en tant qu'individu, pas en tant qu'espèce.
Mais la loi 0 est inférée à partir de la loi 1, où justement l'Humanité est placée au dessus de l'individu, par Asimov lui-même dans son oeuvre (mais cette loi est beaucoup moins connue que les 3 autres).
Le 26/07/2024 à 09h 08
Windows 11 24H2 : des mises à jour incrémentielles, plus petites et rapides à installer
17/07/2024
Le 26/07/2024 à 09h 03
Juste sur les problèmes de version, pour aptitude (et je n'ai pas fait une recherche exhaustive) :
- Apt downloads arch all packages from wrong repo/checks wrong checksum
- apt-get install segfaults with certain repository configurations
- apt ignores versioned provides if non-matching version is installed via another dep
- [apt-get] build-dep can fail if policy selects candidate version that does not satisfy a versioned dependency
- apt-get autoclean keeps old versions when still provided by some source
- apt-get dumpavail does not print all versions
Donc en appliquant ta logique, je pense que le qualificatif de daube est mérité pour aptitude ;)
Le 24/07/2024 à 10h 20
Le nombre de bogue a un instant T ne donne absolument aucune information sur la (non) qualité d'un logiciel. Plus le nombre de bogues est grand, plus le logiciel est utilisé. C'est éventuellement la seule chose que l'on pourrait en déduire.
De plus, bogue dans ce contexte est inapproprié, c'est plutôt ticket qu'il faudrait employer. En effet, des demandes d'évolutions apparaissent aussi en tant que bogue. Et s'il y a des demandes d'évolutions, c'est que le logiciel est aussi utilisé.
Enfin, si le nombre de bogues ouvert reflétait la (non)qualité d'un logiciel, alors aptitude ne fait guère mieux que winget. Faut-il en conclure pour autant que c'est une daube ?
Le 23/07/2024 à 09h 32
Quand le téléchargement est dans un script en hook post-install, ton gestionnaire de paquet ne peut rien faire. Je suis d'accord pour dire que le paquet était mal foutu, mais c'est le paquet fourni par l'éditeur. Donc au bout d'un moment...
Par contre, je n'ai pas souvenir d'avoir eu le problème avec des dépôts officiels. C'était toujours des dépôts tiers.
Fiasco CrowdStrike : Microsoft persiste et signe, tout est la faute de l’Europe
23/07/2024
Le 26/07/2024 à 08h 22
2) source ? Car beaucoup de solutions non open-source sont également audités
3) le nombre de technologies opensource utilisées pour les infrastructures du web et du cloud est un bon indicateur des gains de l'ouverture en terme de part de marché. Est-ce parce que les solutions sont de qualité ? Peut-être. C'est sans doute un des facteurs. Est-ce parce que les solutions sont généralement gratuites ? Très certainement (ne pas oublier que la sécurité est un parent pauvre dans les entreprises !). Est-ce parce que cela offre une indépendance vis-à-vis du bon vouloir tarifaire des éditeurs ? Aussi (cf. récemment Broadcom et vmware par exemple)
Le 25/07/2024 à 20h 49
1) est-ce prouvé que cela augmente la qualité du logiciel ?
2) est-ce prouvé qu'il y aura réellement plus d'audit indépendant ?
3) si avantages il y a, est-ce qu'ils compensent le préjudice que les hackers peuvent trouver en l'examinant directement ?
Le 25/07/2024 à 14h 53
Je n'ai jamais dit que le code source était nécessaire. Je dis que l'accès au code source facilite la tâche par rapport à une décompilation ou une analyse de comportement.
"Les bons hackers appliquent la méthode scientifique pour attaquer et s'adaptent à leurs cibles, et les attaques sont d'autant plus facile si la cible développe un sentiment non-justifiée de sécurité en pensant que l'obscurité va constituer un frein majeur pour l'attaquant, quitte à se bander les yeux pour renforcer ce sentiment."
La sécurité ne reposant QUE sur l'obscurité est une hérésie. Là dessus, tout le monde est d'accord. Maintenant, rajouter de l'obscurité complique les choses pour les hackers, aussi bon soient-ils.
Tu pars du principe pour justifier l'ouverture que si le code est ouvert, alors il sera de meilleur qualité. C'est une assertion qui reste à prouver.
"L'évolution peut être rationalisée en un système d'attaques par force brute aléatoires, arbitraires et parallélisées."
On est d'accord. Mais si on peut orienter les recherches pour que ce ne soit plus de l'arbitraire, on gagne en efficacité. Ce qu'un accès au code source permet plus facilement.
Le 25/07/2024 à 12h 01
Sauf que là, on ne parle pas de trouver une faille en tant que telle, mais de comprendre un mécanisme de détection pour éviter de le déclencher. C'est une complexité tout autre.
Pour le virus biologique, il n'y a aucune "reflexion" de sa part. Il mute (comme tout virus) plus ou moins régulièrement. Si une mutation lui donne un avantage (résistance à un médicament par exemple) et qu'il se trouve en présence d'un contexte dont il peut tirer avantage par rapport aux autres (présence dudit médicament) alors effectivement, il va proliférer, car la concurrence sera éliminée alors que lui non. C'est le principe d'évolution et notamment de la sélection naturelle évoquée par Darwin.
Du coup, le virus ne s'adapte pas en tant que tel (il n'y a aucune volonté). C'est le principe de sélection naturelle. Le hasard.
Si on en revient à son équivalent numérique, un virus détecté par une solution de sécurité, on va avoir plusieurs cas :
- le virus "mute" (nouvelle version) : peut être qu'il passera sous les radars, peut être pas. C'est au petit bonheur la chance
- le virus "mute", mais son créateur connait les mécanismes de défense mis en place par les solutions antivirus et assimilées : il peut "orienter" les mutations pour l'aider à passer outre. C'est beaucoup plus efficace que juste le petit bonheur la chance.
Le 25/07/2024 à 11h 15
Un virus (biologique) n'a, à ma connaissance, pas de conscience lui permettant d'agir et d'anticiper en fonction de la molécule qui lui est foutu devant lui.
Ainsi, et malheureusement, c'est un peu le jeu du chat de la souris. Et qu'on le veuille ou non, la fermeture maximale des solutions n'a pas qu'une explication mercantile (ce qui n'enlève pas pour autant cet argument, juste que ce n'est pas le seul) mais aussi une explication d'efficience. C'est triste, mais c'est ainsi.
Le 25/07/2024 à 09h 35
Niveau serveur, Linux a une très belle part de marché, supérieure à celle de Windows (il suffit de voir Azure :)).
Effectivement, le côté applis web change un peu la donne, dans le sens où il n'y a plus de dépendance forte à Windows comme auparavant. Mais quand il faut gérer l'inertie (que ce soit des utilisateurs ou des techniciens), l'homogénéité d'un parc (plus facile de ne gérer que du Windows ou qu'une seule version d'une distribution linux que 36000 versions différentes).
Sans compter que quand ça marche, pourquoi changer (coucou les aéroports non affectés qui tournaient sur du Windows 3.1 !)
Et pour les appli .Net, tant qu'elles ne sont pas graphiques oui, elles peuvent se passer de Windows. Avec .NET Maui, on a de bons portages sur Linux possible, mais c'est une techno assez récente (d'un point de vue industriel j'entends) et le support Linux est communautaire et non pas officiel (et ça en freine certains).
PS : je suis aussi dev Windows
Le 24/07/2024 à 17h 11
Après, si cela avait été traité par les médias "classiques", on aurait eu droit à "une mise à jour Linux fait planter tous les systèmes" au lieu d'une mise à jour Windows (et encore, le terme Linux étant inconnu de bon nombre de nos concitoyens, je ne suis même pas sûr que Linux aurait été cité)..
Le 23/07/2024 à 17h 05
Et franchement, si ça devait couter 5 milliards de dollars sur 3 ans, je prendrais le risque d'amende. Ça couterait moins cher, surtout en faisant trainer les choses !
Le 23/07/2024 à 15h 25
Vu la criticité de la chose, il n'y a rien d'étonnant à ce que cela n'ait pas été fait, sans compter les coûts induits par ce type de réécriture.
Microsoft n'a pas rien fait non plus, puisqu'il a mis en place un système de qualité pour les drivers en espace noyau.
Je pense qu'à l'époque, personne n'avait songé qu'un pilote puisse se retrouver à faire planter la moitié de la planète en 78 minutes dès lors qu'il était installé. On critique beaucoup Microsoft, mais le problème numéro 1 n'en reste pas moins qu'un fichier de définition en espace utilisateur n'aurait jamais du être capable de faire planter un driver en espace noyau.
Le 23/07/2024 à 13h 54
Les kernels panic du mois dernier ne vont pas trop dans ce sens, sauf à ce que l'utilisation de ces hooks soit récente.Et dans les commentaires, j'ai trouvé celui-ci très instructif :
Bref, cela aurait très bien pu arriver sous Linux.
Malgré des efforts, il y a toujours plus de débris dans l’espace
25/07/2024
Le 25/07/2024 à 10h 41
Merci. J'ai explosé de rire à la lecture de ton commentaire :)Panne des numéros d’urgence : BT condamné à 20 millions d’euros… deux salles, deux ambiances
24/07/2024
Le 24/07/2024 à 16h 41
Le 24/07/2024 à 14h 54
# C’est des vieux Diesel ou voire même des chaudières à la vapeur les Call Servers (Passerelles VoIP / RTC) de chez Orange (en fait conçus & fabriqués par le sous-traitant Itatel) ?Pas forcément. Ce genre de truc, c'est sensé rester online 24h/24, 7j/7. Donc il suffit que quand ça démarre, ça lance toute une série de diagnostics pour s'assurer qu'il n'y a pas eu un soucis / panne matériel pour que cela prenne autant de temps.
[MàJ] La page Wikipédia francophone de la première ministrable du NFP Lucie Castets débattue
24/07/2024
Le 24/07/2024 à 15h 38
Si le NFP était un parti, alors tu pourrais y adhérer et y prendre une carte. Ce qui n'est pas le cas.
Fiasco mondial CrowdStrike : le CEO appelé à témoigner au Congrès américain
23/07/2024
Le 24/07/2024 à 12h 03
Je pensais que le contexte général suffirait à comprendre. Il semblerait que non. Mea culpa.
Le 24/07/2024 à 10h 33
L'espace noyau, c'est, comme son nom l'indique, l'espace noyau (je sais, Lapalisse n'aurait pas fait mieux). C'est le coeur du kernel de l'OS. C'est le truc qui doit impérativement être hyper stable, sous peine de créer des BSOD ou kernel panic (pour prendre l'équivalent Linux)
L'espace utilisateur, c'est ce qui est externe à l'espace noyau, et que potentiellement, un utilisateur peut modifier. Un fichier sur disque par exemple, c'est de l'espace utilisateur. Le fichier de configuration fait partie de l'espace utilisateur, car réside sur un espace de stockage externe au noyau.
Un driver, avant d'être chargé, est en espace utilisateur. Maintenant, il existe des mécanismes pour assurer l'intégrité du driver entre son chargement et son activation effective au sein de l'espace noyau, pour éviter qu'un driver modifié (=fichier modifié sur le système de fichier) par un utilisateur quelconque ne soit chargé.
L'UEFI, décrié par certains, est un mécanisme qui permet justement d'assurer l'intégrité de l'espace noyau dès le démarrage du système.
Maintenant, que la lecture du fichier de configuration se fasse directement par le noyau ou par un programme utilisateur qui transmet ensuite l'information au driver, qu'importe, le résultat est le même : la configuration est transmise depuis l'espace utilisateur vers l'espace noyau, et doit donc, à ce titre, est (re)validé côté noyau. C'est une règle de base de la sécurité : ne jamais accepter sans vérification une entrée utilisateur (le bogue classique en contexte applicatif "classique" de cette règle étant l'injection SQL).
J'espère avoir été plus clair ;)
Le 24/07/2024 à 10h 06
- démarrer normalement
- démarrer en mode sans échec
- démarrer en mode sans échec avec prise en charge réseau
- ouvrir une console
etc.
Mais sinon oui, tu as tout à fait raison : un démarrage en mode sans échec sans intervention de l'utilisateur, c'est une mauvaise idée.
Le 24/07/2024 à 08h 44
- il faut que tout les besoins soient clairement identifiés (ce qui est difficile dans ce genre de situation)
- très certainement remodelé une partie du coeur même du noyau (opération hautement critique).
Sans compter qu'un des points forts de Microsoft reste la rétrocompatibilité. Faire un tel changement aurait sans doute cassé quelques trucs. Je ne connais pas beaucoup d'OS qui permettent de prendre un programme vieux de 25 ans (par ex. sous Windows 98) et de le faire tourner sur un Windows 10 ou 11 juste en cliquant dessus (et non, Linux ne rentre pas dans cette catégorie, il faudra au mieux recompiler le programme si tant est que l'opération reste possible).
Faire en sorte que sa solution soit au même niveau que les autres, c'est potentiellement abaisser la sécurité globale du système. Pas vraiment souhaitable donc.
Rendre les solutions plugables dans Hyper-V n'aurait pas résolu les problèmes. Pour ce qui est virtualisé, sans doute. Pour le reste non.
Là, on est dans une situation qui est un bel exemple de la Loi de Murphy. La situation a été catastrophique, car :
- le driver est un driver noyau
- la solution est très répandue
- la solution est utilisée dans des infrastructures visibles (aéroports, hopitaux, etc.)
- la gestion de la mise à jour est faite par l'éditeur
- un driver en espace noyau lit un fichier de configuration en espace utilisateur
- l'éditeur pousse une mise à jour d'un fichier de configuration chez tous ses clients en même temps
- les clients n'ont pas vraiment de moyen de contrôler la mise à jour de ce fichier de configuration
- la mise à jour faisait planter quasi-systématiquement le système (au point qu'on se demande si elle a été testé !)
Enlève ne serait-ce qu'un de ces points, et la situation critique que nous avons connu il y a quelques jours n'aurait pas eu lieu.
L'argument avancé par Microsoft peut tout à fait tenir la route (je n'ai pas suffisamment d'éléments pour dire si c'est effectivement le cas ou non). Je dis juste qu'il est tout à fait plausible, et le démonter ne sera pas si facile que ça.
[edit]
Par contre, un truc qu'aurait pu faire Microsoft, et cela, sans nécessiter a priori de modification profonde, c'est de détecter ce genre de redémarrages intempestifs pour proposer un démarrage en mode sans échec. Ce qui ne semble pas être le cas ici.
Je suppose que c'est parce que le système avait le temps de booter entièrement.
Le 23/07/2024 à 10h 26
Au sujet du message perso : toujours partant. C'est juste compliqué depuis quelques mois niveau timing et j'avoue que je n'ai pas mis les pieds à La Rochelle depuis des lustres donc yes, ça me tente bien à la rentrée, quand les touristes seront partis. Et autre détail : je suis "sans voiture" actuellement. J'ai une C3 victime des airbags Takata...
Le 23/07/2024 à 10h 23
[edit] Rajout de la partie en italique.
Le 23/07/2024 à 09h 26
Après, est-ce qu'il ne manque pas de culot ? Je ne dirai pas ça. Vu la couverture médiatique et le manque de professionnel d'un grand nombre de journaliste sur le sujet, qui ont titré, à tord, que la faute incombait à une mise à jour de Windows, j'ai presque envie de dire que c'est normal que Microsoft se défende.
Ils se prennent des critiques de toute part, notamment sur le soi-disant manque de sécurité de Windows (il n'y a qu'à regarder les commentaires sur les articles parlant de Crowdstrike sur Next ces derniers jours pour s'en convaincre).
Si fermer le coeur du noyau implique de se prendre un procès pour abus de position dominante, la société est sensée faire quoi ? On peut ne pas être d'accord, mais je trouve que rappeler que la solution n'est pas qu'un problème technique fait tout à fait sens, surtout dans le contexte actuel.
Anecdote : un client me demandait une fois de mettre en place une fonctionnalité. En tant que consultant externe, je suis "aux ordres" de mon client. Mais je l'ai prévenu : s'il voulait cette fonctionnalité à tout prix, je lui ferai signer une décharge comme quoi je l'avais prévenu que la sécurité de la solution serait amoindri, que je l'avais prévenu, qu'il avait décidé de passer outre mon avertissement et d'en assumer ainsi l'entière responsabilité. Bizarrement, j'ai jamais eu ce papier signé et jamais eu à mettre en place cette fonctionnalité ^^
Le 23/07/2024 à 08h 53
Concernant ce fiasco, je tombe sur cet article assez intéressant : https://www.euronews.com/next/2024/07/22/microsoft-says-eu-to-blame-for-the-worlds-worst-it-outage (désolé, en anglais).En gros, ce serait en partie de la faute de l'Europe que ce fisco ait pu prendre une telle ampleur, du point de vue de Microsoft. Un accord européen de 2009 obligerait Microsoft à accorder les mêmes droits aux solutions tierces de sécurité pour des raisons de concurrence. Microsoft n'aurait donc pas pu verrouiller autant qu'il le souhaitait le noyau de Windows, en tout cas, pas sans violer cette accord visant à favoriser la libre concurrence...
Point de vue intéressant qui ouvre d'autres perspectives.
Le 23/07/2024 à 08h 40
L'heure de rendre des comptes arrive. J'espère que partout dans le monde cela fait être un peu la même histoire, car le problème n'est pas resté cloisonné aux Etats-Unis.Sinon, je pense qu'un petit article sur les différentes responsabilités (civil, commercial, pénal, etc.) des éditeurs en cas de problèmes avec leur logiciel, cela sera pas mal. Par exemple, est-il possible de se dédouaner de toutes responsabilités via la licence d'utilisation ? Ou de limiter les dommages et intérêts à un plafond, à la localisation de l'entreprise ou d'un pays ? etc.
En tout cas, je serais très preneur ! Sans oublier l'open source, avec des logiciels qui ont souvent une clause d'absence de garantie. Un logiciel open-source pourrait-il être tenu responsable si un tel fiasco se produisait ? La personne ayant choisi d'utiliser un tel logiciel pourrait-elle alors être tenue responsable ? etc.
Bref, une idée d'article ^^
[edit]
Pour aller plus loin dans l'idée d'article, aborder aussi la notion de compétence. Un client français peut-il attaquer un éditeur américain par exemple ? Si oui, dans quelle condition ? Car par exemple, si l'éditeur américain ne cible que les Etats-Unis, mais que le petit client français achète quand même la solution, c'est radicalement différent de l'éditeur qui va se prendre un .fr, monter un site en français, avoir une filiale en France et faire payer en euro. Et si on inverse les rôles ? Si c'est un éditeur français qui veut être poursuivi par un client américain ? Quel est la juridiction compétente ?
Plantage des Core i9 : Intel a identifié la cause profonde des bugs, un correctif arrive
23/07/2024
Le 23/07/2024 à 18h 40
Le 23/07/2024 à 18h 24
# pas super convaincu par l'explication demicrosoftIntelJe crois qu'on a tellement vu "plantage de Windows suite à une mise à jour" c'est dernier jours que tous les problèmes ont pour source Microsoft, même quand ça ne concerne que le processeur.
Les plus mauvaises langues diront que c'est la responsabilité de Windows de modifier le voltage pour faire en sorte que le CPU ne plante pas
Revenu universel : l’étude financée par Sam Altman publiée
22/07/2024
Le 23/07/2024 à 08h 21
[MàJ] Fiasco CrowdStrike : détails techniques, 8,5 millions de machines touchées selon Microsoft
21/07/2024
Le 22/07/2024 à 16h 05
Pas de bol, vous avez oublier de modifier votre commentaire #12.15 qui en reprenait le copier/coller...
Cela en dit long sur votre état d'esprit. Fin de la discussion.
Le 22/07/2024 à 15h 56
Un code qui génère un accès non autorisé à une adresse très très basse (du style de 0x9C) a de très forte chance d'être provoqué par le déréférencement d'un pointeur NULL, dont un simple test if (v != NULL) protège. Ce n'est pas l'unique possibilité d'avoir ce genre d'erreurs, mais dans la grande majorité des cas, c'est ça.
Donc l'article parle bien de l'adresse 0x9C. Un accès à ce type d'adresse est très majoritairement dû à l'usage non testé d'un pointeur NULL (le fameux déréférencement). Donc, le test proposé par Wosgien (qui protège contre le déréférencement d'un pointeur NULL) sera efficace dans la grande majorité des cas.
Maintenant, et sans vouloir être désagréable, notre échange m'indique clairement que vous n'êtes pas développeur (ou si c'est le cas, j'en suis désolé, mais vous avez de grave lacune sur la notion de pointeur). Dans les deux cas, il me parait inutile de continuer ce dialogue de sourd.
Le 22/07/2024 à 15h 36
Cf. mon commentaire #12.5
Le 22/07/2024 à 15h 25
test->machin++;
}
Alors c'est pas "v", mais "test", mais je parlais bien de ça depuis le début... Cf. mon commentaire #12.5
Le 22/07/2024 à 15h 09
https://onlinegdb.com/03Sut0yrO
Je vais utiliser un argument d'autorité, même si je n'aime pas ça : ça fait plus de 30 ans que je développe et au moins 25 que je fais du C plus ou moins régulièrement, dont de la programmation système et sur système embarqué.
Donc oui, je suis sûr de mon coup et tu te trompes. Ce que je t'énonce là, cela fait partie de la base du C.
Le 22/07/2024 à 14h 06
Certains langages proposent effectivement des mécanismes pour éviter les problèmes de gestion de mémoire, et utilisent plusieurs mécanismes, parfois complémentaire, à cette fin.
Maintenant, nous parlons ici d'un cas particulier, qui est de la programmation système, nécessitant un très bas niveau d'abstraction, ce qu'offre le C et dans une moindre mesure, le C++. Pour de la programmation système, on oublie tous les langages qui dépendent d'un runtime et/ou d'une machine virtuelle.
Ne pas oublier non plus que le C a été initialement inventé pour réécrire de manière "portable" Unix. La gestion de la mémoire se devait donc d'offrir un contrôle important au développeur. Ce n'est pas du laxisme, mais une volonté forte.
Avant son invention, le seul moyen utilisable pour écrire un OS était l'assembleur. Ce qui n'était absolument pas portable, puisqu'on devait alors réécrire entièrement les OS pour chaque architecture et chaque processeur.
A ma connaissance, il n'y a que très peu de langages qui permettent aujourd'hui de faire de la programmation système :
- le C
- le C++ (privé de certaines fonctionnalités comme la gestion des exceptions)
- l'Ada
- le Rust
- l'assembleur
Il en existe surement d'autres, mais dans les plus connus/répandus, je ne pense pas en oublier.
Pour terminer, le coup de la remonté des erreurs par le programme jusqu'à le faire crasher, c'est effectivement plutôt une bonne pratique (pour les exceptions, ça va dépendre du type d'exception et de la robustesse que l'on souhaite donner à son applicatif). Mais ça, c'est possible pour les programmes justement, pas lorsqu'on fait de la programmation système.
Si on faisait ça en programmation système, les BSOD ou les kernel panic seraient légions. Un OS ne doit pas planter. Et on le voit bien aujourd'hui, Windows, Linux, MacOS, FreeBSD, etc. sont très stable et fiable. Un programme qui plante ne fera pas planter le système.
Par contre, lorsque le problème est dans un driver / module noyau... les choses se corsent.