Programmez
Le fil de programmez.com
-
Electron 45 : une longue liste de breaking changes et de nombreux changements
Electron 45.0.0 est désormais la version courante. La version 42 n’est pas supportée. La v45 embarque Chromium 156.0.8078.48, Node.js 24.22.0 et V8 15.6.
Cette nouvelle version apporte de nombreuses casses de compatibilités. Il faudra faire un travail rigoureux de tests avant toute migration en production. Citons par exemple :
- Preload scripts des renderers sandboxés : Le retrait des modules globaux (
events,timers,url,Buffer, etc.) pour optimiser le démarrage correspond aux efforts constants d'Electron pour renforcer l'isolation et la sécurité des contextes sandboxés.- Les workers ne reçoivent l'intégration Node.js que s'ils sont créés par une frame qui l'a activée.
- Fichiers ASAR et écriture : La lecture directe sans copie temporaire avec blocage strict de l'écriture en écriture empaquetée reflète fidèlement les modifications de robustesse du système de fichiers virtuel d'Electron.
- La contrainte chromeMediaSource: 'desktop' n'accepte plus que les identifiants d'écran et de fenêtres renvoyés par desktopCapturer.getSources() ;
- Sécurité des captures (chromeMediaSource, display-capture) : Le resserrement des contraintes autour de desktopCapturer et le renommage des permissions vers display-capture s'accordent avec l'évolution des spécifications de sécurité des flux multimédias Chromium.
- Les méthodes synchrones de safeStorage sont dépréciées, retrait prévu en Electron 46.
- L'API expérimentale contentTracing.enableHeapProfiling() est retirée au profit de l'option nativeHeapProfiling de contentTracing.startRecording().
- Retrait des builds 32 bits (Windows ia32, Linux armv7l) et de l'option openAsHidden.
Electron 45 propose aussi des améliorations et nouveautés :
- L'intégration de l'API de sauvegarde/restauration de fenêtres, la gestion des passkeys iCloud via
app.configureWebAuthn(), ou encore les ajouts pour Linux (app.setBadgeCountetwin.setProgressBarvia D-Bus) correspondent point par point aux ajouts recensés dans le journal des modifications de la v45;- app.configureWebAuthn() pour les passkeys du trousseau iCloud sur macOS ;
- une propriété badge sur MenuItem (macOS 14 et plus) ;
- des boutons d'action dans les notifications Linux ; webFrameMain.printToPDF() pour imprimer une seule frame ; webFrame.getIsolatedWorlds() ;
- un champ initiatorOrigin sur les requêtes webRequest et des protocol handlers, et la méthode DownloadItem.getInitiatorOrigin() ;
- le code d'erreur système dans l'événement child-process-gone ;
- protocol.registerSource(), expérimental, pour servir un scheme personnalisé depuis un répertoire ;
- le support de la Prompt API via localAIHandler dans UtilityProcess.
- Sur macOS, autoUpdater écrit désormais les téléchargements sur disque, reprend les transferts interrompus et applique des deltas binaires.
- Sur Linux, app.setBadgeCount et win.setProgressBar reviennent via D-Bus.
Cette version inclut aussi des dizaines de corrections de bug.
Source : https://releases.electronjs.org/release/v45.0.0
Catégorie actualité:Image actualité AMP:
-
Visual Studio 2026 : arrêter la compilation de la solution à la première erreur
Visual Studio 2026 version 18.11 ajoute une option attendue et demandée : arrêter la compilation de toute la solution dès qu'un projet échoue. Mads Kristensen, qui la présente dans un billet du 15 octobre, résume le problème : quand un projet échoue, Visual Studio continuait de compiler les projets déjà dans la file, et le développeur attendait la fin pour corriger. Bref : du temps de perdu et une build pour rien.
L'option se localise dans : Tools > Options > Projects and Solutions > Build and Run, option : « Stop solution build after first failure ». Activée, elle vide la file des projets en attente et interrompt proprement ceux en cours. La build est alors rapportée comme échouée, pas annulée, un détail important pour les scripts et les outils qui lisent le résultat. L'arrêt vaut pour toute la solution, pas seulement pour les projets qui dépendent de celui qui a échoué.
Selon un benchmark de Microsoft sur une solution de test : après un échec, le temps restant passe d'environ 26 secondes à 1,5 seconde, soit 94 % de moins. Le gain dépend de la taille de la solution et de l'endroit où l'erreur survient.
Le billet précise la portée : l'option règle le moment où un build échoué s'arrête ; elle ne change pas les réglages existants qui décident quels projets sont compilés.
Annonce : https://devblogs.microsoft.com/visualstudio/stop-waiting-on-a-failed-build/
Actualité de la rédaction de Programmez!
Catégorie actualité:Image actualité AMP: -
PHP en dit plus sur les failles critiques du 21 octobre découvertes en 2024
Les CVE-2026-109618 et 2026-109619 ont agité les communautés et de nombreux médias annonçaient l'arrêt d'Internet, le monde au bord du chaos, etc. La fondation PHP a retracé l'historique de ces failles.
Un audit détecte un problème dès 2024 !
PHP fait l'objet d'un audit par outil de sécurité externe. Cela a pu se faire grâce à un financement spécial via OSTIF. L'audit est réalisé par Quarkslab. Des problèmes sont remontés. Dont un... "En corrigeant l'un des problèmes signalés par Quarkslab, un développeur du noyau PHP, sous contrat avec la Fondation PHP, a découvert les premiers signes du problème de mémoire (OOM) à l'origine de la CVE-2026-109618. En 2024, une exploitation potentielle de cette vulnérabilité a été envisagée, mais aucun vecteur concret n'a été trouvé et d'autres problèmes concrets, ayant un impact évident, ont éclipsé ces préoccupations."
Pour résoudre ce problème de out of memory, l'équipe de sécurité PHP développe plusieurs solutions mais chaque proposition introduit des inconvénient dont :
- casse de compatibilité
- risque d'attaque par déni de service
- nombreuses modifications d'extensions externes
Durant plusieurs mois, l'équipe de sécurité ne parvient pas à se mettre d'accord, le développement est arrêté, relancé ou refait. La fondation est obligée d'admettre une défaillance interne de l'organisation : "Nous ne le nions pas : ce retard était dû à une défaillance structurelle, imputable à la fois au processus décisionnel de l’équipe de sécurité et à son manque de ressources. Depuis, l’équipe de sécurité a entrepris de modifier ses processus, et ce travail se poursuit, afin que les décisions soient prises à la majorité et que les compromis soient encouragés."
Sauf que cette non-correction dure des mois. En mai 2026, la fondation crée une équipe de sécurité de l'écosystème PHP, en collaboration avec l'équipe de sécurité interne pour trier et donner les priorités... L'équipe est renforcée par plusieurs personnes.
Début 2026, la fondation rappelle un problème avec Mythos pour tester PHP et la plateforme. Le 30 juillet 2026, un nouvel audit est lancé par Calif.
11 août : ""Ryan A., chercheur chez Calif, a signalé une exécution de code à distance inconditionnelle ayant la même cause que le problème de mémoire insuffisante (OOM) que nous avions découvert en 2024." Cela signifie que les failles out of memory de 2024 sont toujours là.
24 août et 18 septembre : OpenAI et Wiz identifient de nouvelles failles.
Cette succession de failles et des mêmes causes alerte PHP du problème profond et de l'urgence de trouver une solution pérenne. La fondation PHP a soutenu les équipes pour mobiliser les développeurs et fixer les failles. Dans le même temps , PHP signale que la sécurité par IA génère aussi beaucoup de retours et l'équipe de sécurité interne connaît une charge de travail supplémentaire : 15 CVE publiées depuis le 1er juillet et plus de 100 signalements traités dont la plupart, ou tous, se sont révélés non exploitables ou des faux positifs.
20 octobre : la catastrophe se produit !
Les vulnérabilités sont divulguées, 2 jours avant la publication officielle des CVE. Dès 15h UTC, les CVE commencent à circuler. Les détails techniques ne sont pas donnés. Face à l'urgence, le projet PHP avance l'annonce des CVE au 21 octobre. "Avancer la publication d'un jour constituait le meilleur compromis entre la rapidité d'action, le temps nécessaire à la préparation et la simplicité de la procédure de mise à jour pour tous suite à la divulgation des vulnérabilités."
Calif publie par erreur une vidéo montrant un PoC d'exploitation des CVE ! Elle est supprimée immédiatement mais c'est déjà trop tard. Et la vidéo et les informations circulent rapidement le 21 octobre. Le projet PHP précise avoir fourni à plusieurs fournisseurs technologiques des méthodes pour réduire les risques. Ont-elles fuité ?
21 octobre 7h41 UTC : PHP explique que Chainguard n'a pas respecté l'embargo sur les CVE et publie des éléments inlcuant le correctif que le projet PHP a développé. "N'importe quel attaquant pouvait désormais étudier le correctif sous forme binaire, alors que tous les autres utilisateurs de PHP attendaient encore sa publication. Cela a anéanti des semaines de travail menées par de nombreuses parties en vue d'une divulgation coordonnée."
La suite vous la connaissez...
Notre avis : on pouvait se douter que les deux CVE n'étaient pas apparues par magie, surtout quand elles touchent la mémoire. La fondation PHP a le mérite de publier sa vérité sur cette affaire. Nous pouvons faire 4 constats :
1 / les premières failles menant aux CVE sont découvertes dès 2024
2 / les équipes de sécurité PHP n'arrivent pas à se coordonner sur une solution unique et durant des mois, rien ne bouge réellement et aucune décision ne semble avoir été prise
3 / il faut attendre l'été 2026 pour que PHP y voit un problème majeur de ces failles
4 / la fondation PHP reconnaît ses erreurs, la défaillance d'organisation et l'absence de priorité pour les failles de 2024. Mais, elle cherche aussi à rejeter, au moins en partie, la panique des CVE critiques, sur d'autres personnes et éditeurs du marché qui n'auraient pas respecté les règles.
On peut effectivement pointer l'erreur de Calif ou l'attitude de certains fournisseurs mais cela ne dédouane pas PHP sur les conséquences de ces CVE depuis les premières découvertes en 2024.
Texte complet : https://thephp.foundation/blog/2026/10/21/todays-php-security-release-and-how-were-strengthening-php-security/
Catégorie actualité:Image actualité AMP: -
Node.js : misę à jour de sécurité disponible pour les versions 22, 24 et 26
Comme promis, Node.js déploie les mises à jour de sécurité pour les versions 22, 24 et 26, à savoir : 22.23.4, 24.22.1 et 26.12.1. Node prévient : TOUTES LES VERSIONS NON SUPPORTÉES NE SERONT PAS PATCHÉES.
Ces patchs fixent la CVE-2026-111497 permettant une exécution de code distant et des écritures non autorisées avec le décodeur Brotli. Ces versions en profitent pour mettre à jour c-ares, ca-cert, OpenSSL, SQLite et Undici.
Plusieurs autres CVE sont corrigées. Elles permettaient de bypass des hostname de certifcats TLS, problème dans le socket process ou encore une validation impropre d'un certificat (en contexte IPv4), faille dans ZipFile.
Note : https://nodejs.org/en/blog/vulnerability/october-2026-security-releases
Catégorie actualité:Image actualité AMP: -
TinyJS : des applications desktop en JavaScript de 6 Mo, sans Chromium
TinyJS est un framework pour développer des applications desktop en JavaScript, publié sous licence MIT par un développeur indépendant, tarwin. Le principe tient en une phrase : « un backend JavaScript avec accès complet au système, une fenêtre webview native, et rien d'autre ».
Ce qui le distingue est ce qu'il n'embarque pas. Electron livre un Chromium et un Node.js complets avec chaque application : le projet annonce des applications d'environ 6 Mo et les compare à des distributions Electron d'au moins 150 Mo.
TinyJS s'appuie sur la webview du système, WebKit sur macOS, WebView2 sur Windows, WebKitGTK sur Linux, et sur txiki.js, un runtime qui réunit QuickJS, libuv, SQLite et WebAssembly. Face à Tauri, qui utilise aussi la webview du système, la différence est le backend : JavaScript sans l’étape de compilation, là où Tauri demande Rust ; les API système sont intégrées, là où Tauri passe par des plugins. Face à Neutralino, le backend est un vrai processus qui dialogue par socket Unix (named pipe sous Windows), sans port réseau ouvert.
TinyJS supporte macOS 15 et plus, Apple Silicon et Intel ; Windows 10 et 11 ; Linux x86_64 et ARM64, avec glibc 2.35 et plus (Ubuntu 22.04, Debian 12) et WebKitGTK 4.1. Installation sur macOS et Linux (sous Windows, une commande PowerShell équivalente est fournie) :
curl -fsSL https://tinyjs.app/install | sh
tinyjs new myapp
cd myapp
tinyjs dev
tinyjs build
Le projet est jeune : création en juillet 202. À réserver aux tests, mais l'idée est intéressante : pour un outil interne ou un utilitaire, une application d'environ 6 Mo sans navigateur embarqué ni chaîne Rust.
En résumé :
- Des apps de 6 Mo
- Pas d’Electron, ni de Node, ni de Chromium embarqué
- Pas de serveur http
- Backend en JavaScript
- Frontend en HTML, CSS et JavaScript
- Eléments d’interface natifs
Site et documentation : https://tinyjs.app/
GitHub : https://github.com/tarwin/tinyjsapp
Actualité par la rédaction de Programmez!
Catégorie actualité:Image actualité AMP: -
Deno 2.9.8 : mise à jour de sécurité
Deno annonce la sortie de la version 2.9.8. Il s’agit d’un patch de sécurité pour fixer la vulnérabilité eMudhra. Cette mise à jour fixe 12 autres problèmes de sécurité et des bugs.
Liste des corrections :
- fix(compile): check read permission for dynamically imported local files
(#36925) - fix(completions): complete script paths for bare deno run in zsh (#36976)
- fix(core): keep op contexts alive until the isolate is disposed (#37026)
- fix(coverage): skip the V8 code cache while collecting coverage (#36901)
- fix(ext/fetch): bump hyper-util to 0.1.21 and hyper to 1.11.1 to cancel idle
interval when pool empties (#36968) - fix(ext/napi): check napi_create_dataview bounds for overflow (#36962)
- fix(ext/napi): ignore the callback return value while an exception is pending
(#36942) - fix(ext/node): align X.509v1 certificate handling with OpenSSL (#36933)
- fix(ext/node): mock.reset() restores mock.method() implementations (#36886)
- fix(ext/node): support assert message functions and format arguments (#36944)
- fix(npm): validate package link names (#37047)
- fix(tls): distrust compromised eMudhra certificate authorities (#37046)
- fix: bump rand 0.9.x to patched version
Note de version : https://github.com/denoland/deno/releases
Logo Deno : bramaudi
Catégorie actualité:Image actualité AMP: - fix(compile): check read permission for dynamically imported local files
-
PHP : mises à jour de sécurité disponibles
Comme promis, PHP a distribué les mises à jour de sécurité suite à la divulgation de deux CVE critiques plus tôt dans la journée.
Il s’agit des versions : 8.5.12, 8.3.35 et 8.2.35. Attention : les versions de PHP ne seront pas patchées. Ces patchs corrigent les failles permettant d’exécuter du code distant.
Toutes les installations PHP ayant des requêtes web, sont impactées. mod_php est considéré en risque très élevé.
Les vulnérabilités :
- exécution de code distant avec une corruption suite à un dépassement mémoire
- exécution de code distant via un état global obsolète : un état appartenant à une requête peut persister après la libération de sa mémoire. Une requête ultérieure, par le même worker, peut utiliser cet état avant qu’une initialisation ne soit faite
Les distributions Linux recevront des patchs : vérifier auprès de l’éditeur de la distribution
Si vous ne pouvez pas effectuer de mise à jour immédiatement : bien qu'une mise à jour soit la seule solution complète, les mesures suivantes réduisent l'exposition à des vecteurs d'attaque spécifiques, mais ne garantissent pas qu'une installation soit sûre.
Note de version : https://www.php.net/index.php#2026-10-21-5
Catégorie actualité:Image actualité AMP: -
JFrog veut réduire l’angle mort du shadow IA notamment chez le développeur
Cette semaine, JFrog organise sa conférence swampUP à Barcelone. Durant les keynotes du 21 octobre, plusieurs thèmes ont été abordés : les agents, les skills, l’accélération de la découverte des failles par l’IA et comment les corriger. Le shadow IA a été longuement abordé. Pour répondre à ce défi, l’éditeur fait évoluer sa plateforme AI Security. Elle permet de détecter et d’analyser l’ensemble des éléments IA de l’entreprise. La détection est un élément important pour découvrir les IA “cachées”, que ce soit les skills ou les agents qui sont autant de portes ouvertes à des compromissions.
La détection locale du Shadow AI (Local Shadow AI Detection) met en évidence les actifs d'IA exécutés directement sur les machines des développeurs, là où les contrôles des pipelines et des registres n'arrivent pas. JFrog introduit également la nouvelle analyse des actifs d'IA avec Bring Your Own LLM Key (BYOK), qui permet aux clients d'analyser les skills,les plugins d'agents de code et les packages APM avec leur propre instance LLM, afin d'examiner cette couche de la chaîne d'approvisionnement en IA sur une infrastructure qu'ils maîtrisent.
Aujourd’hui, il est facile pour un développeur d’installer un skill, un agent, un LLM depuis son IDE ou une marketplace. Mais ces composants utilisent les identifiants du développeur, ce qui peut être un risque si l’asset IA n’est pas sécurisé.
Local Shadow AI Detection étend la visibilité aux machines des développeurs de la manière suivante :
- Détection des actifs dès leur arrivée : déployée via le JFrog Agent Plugin sur le poste du développeur, via la gestion des appareils mobiles (MDM) ou via les paramètres de l'agent Harness, elle repère les skills, plugins et serveurs MCP, quel que soit le dépôt ou la marketplace d'origine.
- Analyse sur l'appareil local : une analyse déterministe s'exécute sur le poste lui-même, et seules des métadonnées et une évaluation du risque sont renvoyées vers la plateforme JFrog.
- Création d'une base de référence : chaque actif est recoupé avec les données sources de la plateforme JFrog pour déterminer ce qui est approuvé, ce qui permet aux équipes de sécurité d'avancer en toute confiance.
Pour en savoir plus : https://jfrog.com/ai-security/
Catégorie actualité:Image actualité AMP: -
Node.js annonce des mises à jour de sécurité pour le 21 octobre ou peu après
-
php2shell : failles critiques dans PHP
Depuis quelques heures, le monde PHP s’inquiète de deux failles critiques : CVE-2026-109618 et CVE-2026-109619 (CVSS v4.0 : 9.2). Cela concerne le core code du langage et potentiellement tous les outils, serveurs, CMS utilisant PHP. Les failles concernent toutes les versions de PHP depuis la 5.4.
Ces failles, dont les détails ne sont pas totalement connus, permettent d’exécuter du code distant non autorisé.
PHP promet une mise à jour urgente pour ce 21 octobre à 14h UTC. Les détails seront publiés en même temps que la mise à jour.
MàJ 10h07 : seules les branches actives et supportées de PHP seront fixées, à savoir les versions 8.2 et +. Les versions 8.0, 8.1, et plus anciennes, ne seront pas fixées.
MàJ 14h27 : Mattias Geniar fait le point sur les exploits déjà réalisés : https://ma.ttias.be/php-cve-2026-109618-early-mitigation/
Pour le moment, nous ne savons pas quelles seront les versions de PHP qui seront corrigées.
Une solution temporaire : https://github.com/syhunt/php2shell-protection
Catégorie actualité:Image actualité AMP: