Sortie de la 60ᵉ version d’OpenBSD

Posté par  (courriel, site web personnel) . Édité par Ysabeau 🧶. Modéré par patrick_g. Licence CC By‑SA.
15
20
mai
2026
OpenBSD

Ce 19 mai est sorti la soixantième version d’OpenBSD qui a maintenant plus de trente ans. OpenBSD est un système d’exploitation libre de type Unix, multi-plateformes basé sur 4.4BSD avec une attention particulière sur la portabilité, la standardisation, l’exactitude, la sécurité proactive et la cryptographie intégrée. Il est généralement reconnu pour la qualité de sa documentation et ses innovations en matière de sécurité qui sont régulièrement adoptées par d’autres systèmes.

La version 7.9 est accompagnée d’un morceau instrumental et de moult changements dont on pourra citer l’ajout de l’hibernation à retardement, le support des VLAN dans les ponts Ethernet virtuels, le limiteur de créations d’états par source pour packet filter, le support des certificats par IP dans acme-client, plusieurs améliorations de pledge permettant une meilleure mitigation des failles de sécurité et le support de jusqu’à 255 processeurs amd64 (contre 64 précédemment).

Le projet OpenBSD étant le berceau de tmux, LibreSSL et OpenSSH, cette nouvelle version est aussi l’occasion de publier nombre d’améliorations pour ces projets largement utilisés par ailleurs. Pour OpenSSH on pourra mentionner la nouvelle commande ~I ainsi que l’ajout d’une pénalité configurable pour les tentatives de connexions avec un utilisateur invalide.

Journal gestion de failles de sécurité bazardeuse

18
16
mai
2026

le bazar a gagné

La typologie cathédrale/bazar pour décrire deux modes de développement du Logiciel Libre / Open Source a été établie par Eric S. Raymond il y a bientôt 30 ans. Depuis, les grands exemples de cathédrales se sont transformés en bazars et ce modèle a été largement adopté1 par la plupart des projets de Logiciel Libre. C'est à dire que les modification du code sont publiée en temps plus ou moins réel sans attendre qu'une nouvelle version (…)

Journal une ligne du temps de la dernière faille du noyau Linux (une autre)

15
15
mai
2026

Ces derniers jours LinuxFr.org a décidé de rapporter toutes les failles du noyau Linux qui ont un cool nom avec quelques heures/jours de retard. Celle-ci n'a pas de cool nom, ce qui explique sans doute pourquoi personne n'a encore écrit de journal ou de lien. Ici je vais juste détailler la ligne du temps de la divulgation.

2020-10-16 Jann Horn propose un correctif de sécurité à linux-mm
2020-10-17 Jann Horn fait une deuxième tentative
[le correctif n'est jamais accepté]
2026-05- (…)

Journal Exploit Linux local pour passer root : Copy Fail (CVE-2026-31431)

31
30
avr.
2026

La société Theori a publié un exploit (écrit avec Python 3.10) pour le noyau Linux x86-64 pour passer root en local. Il utilise un bug dans les sockets AF_ALG sur une opération AEAD qui existe depuis 2017 (commit). Depuis d'autres exploits ont été écrits tels quel copy-fail-c qui est écrit en C et supporte d'autres architectures CPU (comme AArch64); sous Fedora, il a besoin du paquet glibc-static.

Le correctif (commit) est disponible dans le noyau Linux (…)

Mercator — Cartographie de SI Open Source

Posté par  . Édité par Xavier Teyssier. Modéré par bobble bubble. Licence CC By‑SA.
22
29
avr.
2026
Sécurité

Si vous êtes RSSI, DSI ou architecte dans une entité concernée par NIS2, vous avez probablement reçu en 2024 ou 2025 une lettre de votre autorité de supervision vous rappelant poliment — mais fermement — que la cartographie de votre système d'information est désormais une obligation réglementaire. Pas une bonne pratique. Pas une recommandation. Une obligation.

NIS2 (transposée en droit national dans les pays membres de l'UE) impose aux entités essentielles et importantes de mettre en place des mesures de gestion du risque cyber, parmi lesquelles figure explicitement la connaissance et la documentation de son système d'information. L'ANSSI en France, le CSIRT Luxembourg, le BSI en Allemagne — tous y font référence. Sans cartographie, pas de gestion du risque sérieuse, pas d'analyse d'impact, pas de plan de continuité fiable.

C'est précisément le problème que Mercator tente de résoudre depuis plusieurs années, et le projet continue d'évoluer.