Sortie d'OpenBSD 7.2 ce jour.
Le cycle des sorties d'OpenBSD ne tombe plus systematiquement sur le 1er mai et 1er novembre depuis quelque temps mais globalement elles restent espacees de 6 mois. Le support est assure pour la derniere version publiee et la precedente. La numerotation de ces versions ne suit pas un schema version_majeure.version_mineure, aussi 7.2 pourrait etre lue comme 72, il s'agit de la 53eme publication de 2.1 a 7.2 + une version anterieure.
https://www.openbsd.org/72.html
A noter , deux petits patchs devraient etre rapidement mis a disposition (ASN1 et x509) car corriges depuis le gel definitif du code de la 7.2 le 27 septembre.

Il y a longtemps eu trois varietes: release / stable / current, chacune ayant son arbre code source. Il etait possible de migrer binairement entre versions et aussi via un snapshot de developpement. Les paquets externes sont la aussi disponibles sous forme source a compiler dans un port tree ou sous forme binaire pour release et snapshot. Le systeme gere excellement les jeux de dependance entre ces paquets.
Ceci existe toujours mais avec deux caracteristiques supplementaires depuis quelques annees:
- on peut ajouter des patchs a "release" par binaire, plus besoin de compiler.
- certains paquets externes sont patches et mis a disposition deja recompiles entre deux versions d'OpenBSD, ils sont dits "stable" mais disponibles pour la branche "release"
De fait, plus beaucoup de raisons de ne pas suivre la branche release versionee tous les 6 mois et gerer tout ou la majorite des mises-a-jour via binaires.
A noter pour les aventuriers que les snapshots contiennent parfois du code (compile donc) qui n'est pas encore disponible dans "current" qui represente la branche publique de developpement.

Bien que ce message porte sur OpenSSH et non pas OpenBSD, je le place ici puisque le premier est chapeauté par le second.
La release 8.8 avait déprécié les clefs RSA en SHA1 et incité le mouvement vers ed25519.
Il est question que ssh-keygen génère ed25519 par défaut désormais https://marc.info/?l=openbsd-tech&m=166774468028210&w=2
La prochaine version d'OpenSSH nous indiquera si c'est acté mais par anticipation, prudence pour vos procédures automatisées ou certains accès cloud.

Au passage, la release 9.0 d'avril dernier avait au passage introduit une première lutte pour résister à l'informatique quantique. Et cela évolue https://marc.info/?l=openbsd-tech&m=167358832318821&w=2
Et contrairement à la remarque précédente, ceci est acté dans le code depuis mi-janvier.

hello

si je m'attendais à voir un sujet openbsd par ici...
après tout comme sur reddit/hfr/consors..
cependant c'ets un os orienté serveur, et ultra sécurité
j'ai vu le projet isotop, assez porteur
je me suis interrogé sur un équivalent d'yunohost basé sur bsd..

mais j'admets, qu'à minima utiliser openbsd dans les telcos pour remplacer la box abonné final est un projet intéressant
surtout si on met en avant le coté cyber... et en ces temps

À propos d'OpenBSD, j'avais trouvé intéressant ce site : https://isopenbsdsecu.re/

et
https://why-openbsd.rocks/


mais la problématique d'openbsd, c'est doublement :
que sur laptop/desktop, à moins d'avoir un pc récent, c'est assez lourd/lent comme système
et le bat blesse aussi sur la prise en charge du matériel : cartes graphiques , cartes wifi.. sur sept ordis portables testés, seuls 2 machines ont les deux, fonctionnelles et rrepérées (nvidia, broadcom, catastrophique dans l'OSS)

sinon pour du serveur/routeur, ca passe..

Quand je vois l'énergie importante qui est mis en place coté Linux pour suivre le matériel, je me doute que cela doit être compliqué coté BSD.

Il suffit de regarder https://launchpad.net/ubuntu/+source/linux-firmware/+changelog ce sont une centaine de nouveaux matériels rajoutés chaque mois (des touches propriétaires d'un PC portable aux cartes réseaux 100 Gb/s, c'est varié).

Adolescent, j'étais fan de BeOS, un OS alternatif français et sa grande faiblesse était le support matériel limité (il fallait s'assembler un PC avec les composants supportés pour avoir un truc vraiment fonctionnel).

En 2023, la marche pour créer un nouveau système d'exploitation qui a un support des n'importe quel PC semble désormais trop haute...

OpenBSD arrive à récupérer des dev réalisés pour Linux coté drivers ?

mwif, dans les SE "récents" qui font un peu "old-school", ya surtout haiku qui reprend beos sur certaines lignes.. et qui colle une volée énorme à reactos, jamais vraiment stable en presque vingt ans de dev.. alors qu'haiku (pour l'avoir testé) est bien plus efficace sur certains points..

quant aux drivers coté openbsd, leur logique est simple :
soit c'est OSS et en général ca passe et c'este bien supporté
soit ils se débrouillent pour faire au mieux.. mais c'est clair que pour les cartes broadcom, yen a moins d'une sur deux qu'est supportée
le pire c'est vraiment nvidia, c'est de l'affichage basique de chez basique

là où je crois que ubuntu et meme debian commencent à intégrer du "blob/binaire" pour supporter du hardware, histoire de pas trop couler sous les critiques du "sam'ach'pas", openbsd n'en est pas vraiment ouvert..

À propos d'OpenBSD, j'avais trouvé intéressant ce site : https://isopenbsdsecu.re/

De temps en temps on a droit à ce genre de papier. Ca fait plus de vingt ans qu'il faut déboulonner la statue, briser le totem et rayer le nom du dictateur bénévole d'OpenBSD.
Cependant quand on va au-delà des dires des "rézosocio" et de quelques aigreurs locales, le constat varie peu lorsqu'on scrute les CVE et les zero days en nombre et sévérité chaque année affectant réellement tel ou tel système.
J'utilise l'OS des "masturbating monkeys" depuis 2006 et, personnellement, rien à reprocher question sécurité et on devrait même dire approche de la sécurité. Ironiquement c'est après des incidents majeurs pour lesquels l'OS fut mieux prémuni que ce genre de papier se pointe comme si cela pouvait justifier la propre situation d'autres OS.
Parfois on vire dans la tragi-comédie. Par exemple depuis quelques mois le projet s'attaque à un aspect particulier de protection mémoire et dès l'annonce publique on a vu fleurir des commentaires sur l'inutilité de la démarche, sachant que d'autres OS voudraient exploiter des caractéristiques internes de processeurs récents pour se prémunir. Le gag c'est quand dans la justification on colle des échanges où un ingé Intel stipule que cela ne couvre pas tous les cas. Et puis après avoir subi spectre et consorts, même en tant que béotien je trouve curieux de s'en remettre aux fabricants de cpu pour garantir certains aspects de sécurité. Comme si on n'avait rien appris.
La meilleure reste pour moi quand "ils" ont fait croire que les services gouvernementaux américains avaient placé, il y a longtemps, une faille via le système de génération de nombre aléatoire / entropie. Il avait quand même fallu procéder à un audit. C'est dingue ce que l'égo de certains amène à faire. Là encore si j'ai bonne mémoire c'était quand on s'était aperçu de la faiblesse de ces RNG dans d'autres OSes.

Ceci dit dans le cadre des usages restreints que la plupart des gens sur ce forum (j'imagine) ont de leur infrastructure domestique, ce qui importe le plus c'est la correcte mise en oeuvre des défenses quel que soit l'OS, plutôt que de savoir qui a la plus grosse.

pour le support matériel effectivement c'est très orienté sur la clareté du code, et des différents docs à dispo
c'est clair que openbsd n'a pas l'ambition de ses organisateurs, à savoir outrepasser le simple domaine routeur/serveur (aka passif) face aux actifs appareils utilisateurs
ils sont hyper drastiques sur l'ouverture du code source, et des licences correspondantes
pour hammer2 je crois que c'est mal barré, au meme titre que d'autres implémentations.. je crois savoir que le licensing joue presque autant que la dispo des inforamtions afin d'adapter le matos à openbsd

openbsd/netbsd partagent beaucoup de choses, mais sont clairement une chapelle à part de freebsd ; ce dernier partage avec haiku sa pile réseau, par ex (donc beaucoup plus de composants supportés sur haikus qu'opensd..)


edit: un OS réseau tournant sous oepnbsd (cas très rare):
https://marketplace.cloud.vmware.com/services/details/halon-vsr-virtual-security-router/?slug=true