Le 21 octobre 2026, le projet PHP publie les versions 8.5.12, 8.4.27, 8.3.36 et 8.2.35 pour corriger deux vulnérabilités d’exécution de code à distance, référencées CVE-2026-109618 et CVE-2026-109619.

Surnommées « PHP2Shell », elles sont notées 9,2 sur l’échelle CVSS v4.0 et peuvent permettre à un attaquant non authentifié d’exécuter du code sur un serveur vulnérable.

Pour de nombreux administrateurs, la mise à jour est passée par Ondřej Surý.

Ce développeur tchèque n’a pas découvert les failles et n’a pas écrit le correctif initial. Son travail consiste à transformer le code source de PHP en paquets .deb installables sur Debian et Ubuntu, ce qui inclut la gestion des dépendances, des scripts d’installation, de la configuration et des mises à jour de sécurité.

Deux dépôts très utilisés

Ondřej Surý se présente comme le principal empaqueteur Debian de PHP et maintient les paquets publiés sous l’étiquette DEB.SURY.ORG. Il est l’un des mainteneurs des paquets PHP de Debian, avec l’équipe « Debian PHP Maintainers » et Lior Kaplan. Il exploite aussi deux canaux de distribution : packages.sury.org pour Debian et le PPA ondrej/php pour Ubuntu.

Ces dépôts permettent d’installer plusieurs versions de PHP sur une même machine et d’accéder à des versions plus récentes que celles des distributions stables. Ils servent aussi à rétroporter des correctifs vers des branches qui ne reçoivent plus de mises à jour officielles, comme PHP 7.4 ou 8.0.

Des backports pour les branches anciennes

Le projet PHP ne publie plus de correctifs officiels pour PHP 8.1 et les versions antérieures. Il a fourni des backports sources pour certaines branches anciennes. Ondřej Surý a repris ces correctifs, les a intégrés à ses paquets et les a publiés pour l’ensemble des branches qu’il maintient, de PHP 5.6 à 8.1.

Les administrateurs concernés n’ont ainsi pas eu à recompiler PHP ni à reconstruire leur environnement : une mise à jour APT standard suffit. Le changelog du paquet php8.4 8.4.27-1~deb13u1, attribué à Ondřej Surý, mentionne explicitement les deux CVE.

Cette dépendance a des limites. Certaines configurations très anciennes ne sont pas couvertes : PHP 7.2 sur Ubuntu 20.04, par exemple, reste figé dans son PPA et ne dispose pas de mise à jour par ce canal.

Ondřej Surý dirige l’ingénierie DNS à l’Internet Systems Consortium (ISC) et est associé au développement de BIND, serveur DNS open source. Il préside le groupe de travail DNS Operations (dnsop) de l’IETF et est auteur ou co-auteur de plusieurs RFC consacrées au DNS et à DNSSEC. Sur GitHub, il utilise le pseudonyme oerdnj.

Son activité de mainteneur PHP est bénévole et menée en parallèle de son poste à l’ISC.

Photo : © Internet Systems Consortium 

The post PGP2shell : Ondřej Surý, le mainteneur qui a acheminé les correctifs vers Debian et Ubuntu appeared first on Silicon.fr.

La communauté Debian a désormais son portail d’inférence.

Scaleway le finance et l’héberge en tant que sponsor du projet. Il fournit une réserve mensuelle de crédits partagée entre les contributeurs qui ont le statut de développeur ou de mainteneur.

Deux modèles sont proposés : DeepSeek V4 Flash et GLM-5.2. L’accès se fait via un proxy LiteLLM. Des quotas hebdomadaires s’appliquent : 10 $ pour les développeurs, 25 $ pour les mainteneurs. Ils sont toutefois flexibles : Debian permet de les réinitialiser dès lors que la projection de dépense globale ne dépasse pas l’enveloppe mensuelle.

Les contributeurs s’authentifient via leur compte Salsa (GitLab), qui fait le lien avec leur identité Debian.

Debian autorise un « usage responsable de l’IA générative »

L’ouverture de ce portail fait suite à un vote qui a divisé la communauté. Fin août, celle-ci a décidé d’autoriser un « usage responsable de l’IA générative ».

Huit propositions étaient en lice. La gagnante se résume ainsi : Debian n’encourage pas le recours à l’IA générative, mais ne l’interdit pas non plus. Il n’impose pas d’en divulguer l’usage, mais le recommande. Les standards déjà prévus pour les contributeurs (qualité, justesse, maintenabilité, conformité à la loi…) continuent à s’appliquer. Avant de réaliser des actions impactantes (soumission massive de bugs ou de correctifs, modifications de code à grande échelle…), les contributeurs doivent lancer une discussion. Ils ne divulguent pas à des services d’IA tiers les éléments non publics concernant Debian, sauf si c’est pertinent et explicitement autorisé.

Cette proposition ne prétend pas trancher la question du statut juridique des outputs. Un Français figurait parmi ses soutiens (ses « parrains », dans le jargon Debian) : Lucas Nussbaum. Ce chercheur à Inria, membre communauté depuis 2005, contribue notamment à la brique Ultimate Debian Database, qui vise à unifier les données de plusieurs services (dépôt de paquets, système de suivi de bugs…) dans une base SQL.

Lucas Nussbaum était aussi dépositaire d’une proposition. Arrivée en troisième position, elle était dans le même esprit que la gagnante. Elle en reprenait les grandes lignes, mais imposait entre autres que l’usage de l’IA soit « clairement visible pour tout le public cible »,  indépendamment du type de contribution. Elle insistait par ailleurs davantage sur la responsabilité individuelle des contributeurs, en particulier sur le respect du droit d’auteur.

Une communauté divisée… et des défections à l’issue du vote

Reflet de la division de la communauté Debian, la proposition arrivée en deuxième position invitait à préférer, dès que possible, les « créations humaines » à la GenAI. Elle n’exigeait pas de transparence le cas échéant, mais l’encourageait. Elle imposait surtout de garantir à quiconque le droit de ne pas accepter les contributions assistées par une IA.

Une autre proposition tolérait l’usage de la GenAI pour l’exploration, l’analyse, la critique, etc. mais pas pour la production même. Motif principal : le traitement des contributions IA engendre un surcroît de travail qui érode la confiance et la compréhension mutuelle au sein de la communauté.

Antoine Le Gonidec faisait partie des « parrains » de cette proposition. L’intéressé, à qui on doit ./play.it (logiciel libre qui construit, à partir d’installeurs Linux, Windows et macOS, des paquets adaptés à diverses distributions), en soutenait deux autres de la même teneur. L’une appelait à « rejeter les LLM autant que possible », elle interdisait en particulier leur usage pour la rédaction de messages destinés à des humains. Parmi les raisons invoquées :

• Dévastation des mécanismes de construction des communautés du logiciel libre
• Dégradation de l’environnement
• Exploitation des auteurs
• Ébranlement de l’hébergement web ouvert par de l’extraction agressive
• Pollution du patrimoine informationnel
• Risques pour la santé mentale des utilisateurs
• Création de bulles économiques et distorsion du marché informatique

À l’issue du vote, Antoine Le Gonidec a rendu son tablier. L’autre proposition qu’il soutenait consistait à proscrire toute contribution écrite impliquant un LLM. Elle mettait l’accent sur la surcharge de relecture et la dépendance à l’IA chez les nouveaux contributeurs. Ainsi que sur les problèmes de qualité (exemple sur l’empaquetage, dont la syntaxe et les bonnes pratiques ont changé avec le temps) et de droit d’auteur – sachant que Debian n’autorise pas les contributions dont le statut à cet égard est flou.

* Il y avait 1045 développeurs votants. Debian utilise une variante de la méthode Condorcet, selon laquelle gagne le candidat qui bat chacun des autres en duel singulier.

Logo © Valessio Brito

The post Après son vote en faveur de l’IA, Debian ouvre un portail d’inférence appeared first on Silicon.fr.

Bonne nouvelle les amis, je viens de vous mettre en ligne un sélecteur de distribution Linux !! 35 distributions dans la balance, vingt questions max et à l'arrivée, le nom du Linux qu'il vous faut !

Parce que oui, la "meilleure" distribution Linux n'existe pas dans l'absolu. En fait, le bon choix dépend de votre machine, de votre usage et du temps que vous acceptez d'y passer. Posez la question à deux personnes, l'une répondra Linux Mint, l'autre CachyOS, et les deux auront raison !

L'outil vous demande vos usages et ce que vous avez sous la main... L'âge de la machine, la RAM, la carte graphique, un Windows à garder à côté, et ce que vous comptez en faire, jouer compris.

Le questionnaire se raccourcit ensuite selon ce que vous avez déjà répondu et au final, vous repartez avec une distribution, sa fiche technique et 2 alternatives si celle-là ne vous branche pas.

J'ai remarqué que ce qui manquait à la plupart des classements de ce type, c'était le "pourquoi pas cette distrib ?". C'est pour cela que mon sélecteur affiche aussi les distributions écartées avec la raison de leur élimination, et celles qui ne démarreront même pas chez vous. Hé oui, un vieux PC en 32 bits n'a plus grand monde à se mettre sous la dent depuis que Debian 13 a supprimé son noyau i386.

Et quand Linux n'est pas la réponse à votre besoin, il vous prévient. Par exemple, si votre travail dépend de la suite Adobe ou d'un jeu avec un système anti-triche, l'outil ne fera pas semblant du contraire.

Et bien sûr, tout cela tourne exclusivement dans votre navigateur, et rien ne part ailleurs dans le cloud. En plus c'est gratuit ! 35 distributions ne font évidemment pas tout l'écosystème Linux, et j'ai dû faire des choix mais ça vous donne déjà un nom précis sur lequel vous lancer en toute sérénité.

Et si vous voulez découvrir les autres services Korben c'est par ici .

Si vous avez un Raspberry Pi et que Chromium commence à vous fatiguer, le VRAI Chrome, celui des chads que vous êtes, est enfin dispo en ARM64 !! Enfin, dispo... Si vous savez où chercher, parce que la page de téléchargement de Google vous propose toujours l'installeur amd64, qui ne tournera jamais sur votre machine. C'est Joey Sneddon, d'OMG! Ubuntu, qui a trouvé la combine en bidouillant l'URL depuis son Pi 5.

Avant toute chose, vérifiez que vous êtes bien en 64 bits, parce qu'un système 32 bits refusera le paquet :

dpkg --print-architecture

Si ça répond arm64, le fichier est là , 126 Mo. Il s'installe comme n'importe quel .deb local, en laissant apt gérer les dépendances :

wget https://dl.google.com/linux/direct/google-chrome-stable_current_arm64.deb
sudo apt install ./google-chrome-stable_current_arm64.deb

Le RPM existe aussi pour les distributions qui préfèrent, en remplaçant la fin du nom par aarch64.rpm.

J'ai ouvert le paquet pour regarder ce qu'il y avait dedans. Son fichier de contrôle annonce google-chrome-stable en version 150.0.7871.186, architecture arm64, un peu plus de 400 Mo une fois installé. Soit exactement la même version que le paquet x86 poussé le même soir. Le même Chrome, à la même révision.

Et le canal stable n'est pas seul. Le dépôt de Google sert aussi la beta (151.0.7922.47), la dev (152.0.7967.2) et la canary (152.0.7974.0) pour les puces ARM, et son fichier Release déclare noir sur blanc les deux architectures. Les quatre canaux ont été publiés dans la même minute que leurs équivalents x86.

Est-ce qu'on se retrouve coincé sur cette version, à re-télécharger le .deb à la main tous les mois ? Non. Le script de post-installation contenu dans le paquet ajoute le dépôt Google en précisant l'architecture, et les cinq paquets y sont indexés en arm64 exactement comme en x86. Les mises à jour ont donc de quoi arriver par apt, comme d'habitude.

Alors pourquoi s'embêter, puisque Chromium tourne sur ARM depuis des années ? Pour deux trucs. D'abord ma synchro du compte Google, qui ramène favoris, mots de passe et extensions. Et ensuite, Widevine, le module DRM, qui est ici un vrai binaire aarch64 et pas une couche de compatibilité comme l'émulateur FEX financé par Valve . Netflix et les autres plateformes à DRM s'ouvriront enfin sur un SBC !!!

Mais avec une nuance à connaître avant de vous réjouir qui est que sous Linux, Widevine reste au niveau "Software Secure". Cela veut dire que sur Netflix, la qualité plafonnera entre 720p et 1080p. De la HD donc et pas de la 4K. Désoléééé !

Google avait promis tout ça en mars, pour le deuxième trimestre et son billet annonçait même une installation via chrome.com/download pour les autres distributions, ce qui est malheureusement le morceau qui manque aujourd'hui.

Cela veut dire aussi que rien ne garantit que ce paquet soit considéré comme étant prêt par ses auteurs donc si votre machine doit rester stable, laissez passer quelques semaines avant de vous y essayer.

Manque plus que quelqu'un chez Google ait le courage d'appuyer sur "publier".

Source

Sur Debian, tous les nouveaux packages doivent désormais être reproductibles.

Sur un environnement tel que décrit dans le fichier buildinfo, la compilation du package source devra créer un deb identique au bit près.

Cette initiative contribue à la sécurité de la supply chain logicielle, en favorisant la détection des paquets altérés.

Les builds reproductibles, portés par l’« effet Snowden »

Dans la communauté Debian, le sujet des builds reproductibles avait véritablement pris son essor à l’été 2013, dans la lignée des révélations d’Edward Snowden.

Les patchs se sont alors succédé pour, par exemple, supprimer les données non déterministes dans des bibliothèques statiques, stabiliser l’ordre de génération de champs de contrôle… ou ajouter aux archives le fameux fichier buildinfo décrivant la configuration des environnements de build.

Au dernier pointage, plus de 98 % des paquets dans les archives Debian – hors architecture s390x – ont été rendus reproductibles.

Debian a emmené d’autres Linux dans son sillage

Parallèlement, Debian a impulsé un mouvement plus englobant : le projet Reproducible Builds. Dans ce cadre, des distributions comme NixOS et Arch Linux ont rendu reproductibles certaines de leurs images de base.

Le projet est rattaché à la Software Freedom Conservancy, organisation à but non lucratif de droit américain. Ses principaux sponsors financiers sont l’Open Technology Fund (financé essentiellement par le gouvernement américain) et le Sovereign Tech Fund (filiale de l’agence fédérale allemande pour l’innovation de rupture). Proxmox est aussi dans la boucle. Google le fut, comme Siemens et Mullvad VPN. 1&1, DigitalOcean et Infomaniak procurent des ressources de calcul.

Reproducible Builds a identifié une quinzaine de variables d’environnement dont la présence est susceptible d’engendrer des packages non reproductibles. Parmi elles :

• Horodatages
• Usernames ou hostnames
• Schémas d’encodage des fichiers
• Nombres aléatoires (UUID, clé privée/publique, graine de hachage…)
• Références à des adresses mémoire
• Informations d’architecture (version de kernel, par exemple)
• Locales

Illustration générée par IA

The post Debian passe finalement aux builds reproductibles appeared first on Silicon.fr.