OpenBSD 5.5 : nous ne voulons pas retourner dans le passé !

Posté par Loïc Blot (site web personnel) le 02 mai 2014 à 13:08. Édité par BAud, claudex, ZeroHeure, patrick_g et Benoît Sibaud. Modéré par ZeroHeure. Licence CC By‑SA.

Étiquettes :

mai

2014

Comme tous les 6 mois une nouvelle version d'OpenBSD est publiée.

OpenBSD est un système d'exploitation orienté sécurité et réseau, dont les principaux avantages sont la stabilité, grâce aux audits sur le code source, mais également l'ensemble très large de fonctionnalités réseau qu'il fournit.

Mises à jour

Améliorations sur l'installeur

L'installeur d'OpenBSD gère désormais l'installation automatisée (autoinstall). Cette installation automatisée permet de déployer ou mettre à jour rapidement OpenBSD par le réseau en spécifiant un fichier de réponses. Ce fichier est distribué via un serveur HTTP dont l'adresse est renseignée dans l'option next-server du DHCP. Cette installation est possible à la fois en installation par le réseau (netboot) et par le CD-ROM.

time_t 64 bits

Le problème actuel de la variable time_t est qu'elle est codée sur 32 bits dans tous les systèmes UNIX. Le 19 janvier 2038 à 3h14 et 7 secondes cette variable atteindra sa valeur limite, causant des problèmes graves, avec la réinitialisation de celle-ci à zéro.

L'équipe d'OpenBSD a fait un énorme travail afin de convertir le type de variables en 64 bits, de corriger tous les programmes inclus dans la distribution et patcher/auditer les différents ports.

Packet Filter

Packet Filter inclut désormais un nouveau système de queue afin de gérer la qualité de service.
Le paramètre received-on peut désormais prendre pour valeur any afin de correspondre à toutes les interfaces, excepté celles de loopback.
La politique de blocage par défaut dans le pf.conf de base est désormais un block return.

Sécurité

OpenBSD ne garantissait pas la sécurité par la signature cryptographique des paquets. C'est désormais chose faite, les paquets et la distribution sont désormais signés via l'outil signify.
relayd gère désormais la fonction Perfect Forward Secrecy de TLS avec ECDHE (courbe elliptique Diffie-Hellman). Cette option est désormais activée par défaut.
Le générateur de nombres aléatoires est désormais initialisé par le bootloader.
Le protecteur de la pile du noyau est également initialisé par le bootloader.

Réseau

Prise en charge de VxLAN
Amélioration de la gestion du déchargement des sommes de contrôles TCP/UDP/ICMP (checksum offload)
Activation de la prise en charge de domaines de routage IPv6 (ping6, traceroute6…)
tcpdump peut désormais détecter des sommes de contrôle incorrectes sur ICMP et ICMPv6
Diverses améliorations sur dhclient et dhcpd.

Performances

Les relations entre le cache des tampons et le démon de swap ont été améliorées.

Logiciels

Voici une liste non exhaustive de logiciels inclus dans OpenBSD 5.5

Gnome 3.10.2
KDE 4.11.5
PostgreSQL 9.3.2
Postfix 2.11
PHP 5.4.24
Firefox 26
OpenSSH 6.6
OpenSMTPd 5.4.2

Pilotes

Gestion des cartes réseau virtuelles VMware VMXNET3
Gestion des contrôleurs SCSI VMware Paravirtual
Gestion des contrôleurs SCSI virtio
Gestion des périphériques de nombres aléatoires virtio
Gestion des trackpad Broadcom présents dans les Macbook récents
KMS gère désormais les sorties DisplayPort
Ajout du système de fichiers tmpfs
Plusieurs améliorations sur la couche FUSE.

Plateformes matérielles

alpha : gestion multi-processeur
aviion : gestion des processeurs AViiON
armv7 remplace la prise en charge de l'architecture Beagle.

LibreSSL et HeartBleed

Malgré la sortie de cette version 5.5 et le fork de la bibliothèque OpenSSL en LibreSSL, orchestré par l'équipe d'OpenBSD afin de nettoyer et auditer le code d'OpenSSL, le processus de sortie de la version 5.5 n'a pas permis de patcher la faille avant création de la distribution. Il faut ainsi patcher la libssl d'OpenBSD après mise à niveau/installation.

Aller plus loin

Annonce officielle (438 clics)
Liste exhaustive des changements (189 clics)
Chanson "Wrap in Time" de la version 5.5 (244 clics)

# Précisions

Posté par MTux le 02 mai 2014 à 13:24. Évalué à 10.

nous ne voulons pas retourner dans le passé !

Pour préciser, cela est une référence au logo de la 5.5 qui est un clin d'oeil à Retour vers le futur.

Malgré la sortie de cette version 5.5 et le fork de la bibliothèque OpenSSL en LibreSSL, orchestré par l'équipe d'OpenBSD afin de nettoyer et auditer le code d'OpenSSL, le processus de sortie de la version 5.5 n'a pas permis de patcher la faille avant création de la distribution. Il faut ainsi patcher la libssl d'OpenBSD après mise à niveau/installation.

C'est surprenant. En effet sur les miroirs de téléchargement, l'ISO de la 5.5 est datée du 5 Mars 2014. Or la date de release était le 01 Mai 2014. En gros cette 5.5 était prête depuis 2 mois, rien n'a changé. Pourquoi ce correctif n'a-t-il pas été intégré ?? Cela me semble un petit peu étrange (pour ne pas dire exagéré !). En effet le changelog ne mentionne pas la faille heartbleed.
- [^] # Re: Précisions
  
  Posté par Loïc Blot (site web personnel) le 02 mai 2014 à 13:39. Évalué à 4.
  
  D'après les différentes discussions que j'ai pu voir sur @tech, le processus de release d'OpenBSD étant strict et lancé, il était impossible de fournir un release patché.
  
  Veepee & UNIX-Experience
- [^] # Re: Précisions
  
  Posté par ulver le 02 mai 2014 à 13:43. Évalué à 10.
  
  Si je ne m'abuse : 5.5 est passé en bêta le 12 janvier 2014, et a dû être finalisé quelques semaines/mois après (sûrement vers le 5 mars comme tu l'as vu). A partir de ce moment, l'iso est créé et ne bougera plus, les cds, posters etc etc sont finalisés, et le tout sort le 1er mai.
  
  En résumé, c'est toujours le cas : l'iso d'une release est créé un ou deux mois avant la sortie officielle, et les 2 mois qui suivent servent à créer les cds etc.
  Il ne faut pas oublier que les cds sont une grosse part de leurs revenus. Et d'ailleurs, ils sont de très bonnes qualités, avec des thèmes très sympas et des stickers qui vont avec ;)
  
  Si je me trompe, n'hésitez pas à corriger.
  - [^] # Re: Précisions
    
    Posté par ckyl le 02 mai 2014 à 14:05. Évalué à 10.
    
    Il ne faut pas oublier que les cds sont une grosse part de leurs revenus. Et d'ailleurs, ils sont de très bonnes qualités, avec des thèmes très sympas et des stickers qui vont avec ;)
    
    C'est clair que j'utilise OpenBSD pour avoir des themes très sympas et des stickers plutôt qu'un OpenSSL non troué. Il faut savoir définir les priorités d'un projet et tenir la barre !
    - [^] # Re: Précisions
      
      Posté par walken le 02 mai 2014 à 14:17. Évalué à 8.
      
      C'est une grosse part de leurs revenus qu'il a écrit. Ensuite, non tu n'utilise pas OpenBSD pour les thèmes et les stickers, mais bien pour la stabilité et la sécurité. Ce qui passe dans ce cas ci, par un processus très stricte.
      
      Maintenant si tu n'est pas capable de patcher OpenBSD, je ne crois pas que ça soit le système qu'il te faille.
    - [^] # Re: Précisions
      
      Posté par ulver le 02 mai 2014 à 14:27. Évalué à 9. Dernière modification le 02 mai 2014 à 14:27.
      
      Même si je sens un peu l'ironie/troll dans tes propos, je me permets de te répondre : si tu veux un OpenSSL non troué, pas de soucis : le patch est disponible depuis le 8 avril 2014 : http://ftp.openbsd.org/pub/OpenBSD/patches/5.4/common/007_openssl.patch
      
      Il n'a juste pas pu être intégré dans l'iso 5.5 car les cd étaient déjà partis au pressage.
      Il faut juste penser à patcher à l'install de 5.5 (recompiler en suivant la doc qui est extrèmement bien faite, ou en suivant les patchs binaires fournis par M:Tier dont j'ai parlé dans un autre commentaire).
      
      C'est un peu comme quand tu télécharges l'iso de Debian 7.0, quand tu fais un apt-get update && apt-get upgrade, y'a des maj de sécurité qui sont parus entre le moment où l'iso a été créé et le moment où tu l'as installé. Dans 6 mois, pour OpenBSD 5.6, ce patch sera directement dans l'iso.
      - [^] # Re: Précisions
        
        Posté par Loïc Blot (site web personnel) le 02 mai 2014 à 14:40. Évalué à 3.
        
        Et ils auront intégré LibreSSL, j'ai hâte de voir ce que ca va donner !
        
        Veepee & UNIX-Experience
        
        [^] # Commentaire supprimé
        
        Posté par Chriss le 02 mai 2014 à 15:16. Évalué à -6. Dernière modification le 02 mai 2014 à 15:35.
        
        Ce commentaire a été supprimé par l’équipe de modération.
        
        [^] # Re: Précisions
        
        Posté par Benoît Sibaud (site web personnel) le 02 mai 2014 à 15:35. Évalué à 9. Dernière modification le 02 mai 2014 à 15:40.
        
        Oh un « SEO Manager & Ninja Linker » qui vient placer de manière très subtile un lien publicitaire dans le premier commentaire d'un compte nouvellement créé, avec un compte qui arbore comme page perso le même lien publicitaire ?
      - [^] # Re: Précisions
        
        Posté par MTux le 02 mai 2014 à 19:37. Évalué à 6.
        
        Il faut juste penser à patcher à l'install de 5.5 (recompiler en suivant la doc qui est extrèmement bien faite, ou en suivant les patchs binaires fournis par M:Tier dont j'ai parlé dans un autre commentaire).
        C'est un peu comme quand tu télécharges l'iso de Debian 7.0, quand tu fais un apt-get update && apt-get upgrade, y'a des maj de sécurité qui sont parus entre le moment où l'iso a été créé et le moment où tu l'as installé.
        
        D'accord avec toi, sauf que sur Debian une mise à jour c'est simple (apt-get télécharge le correctif binaire et l'installe) alors que sur OpenBSD il faut recompiler le système ou le composant, ce qui est quand même beaucoup plus long (surtout sur du matériel embarqué de faible puissance!). De plus apt-get automatise tout, alors que sur OpenBSD il faut connaître l'existence des patchs, les récupérer, les compiler, ce qui peut prêter à confusion quand il y en a beaucoup.
        
        [^] # Re: Précisions
        
        Posté par ZeroHeure le 03 mai 2014 à 01:22. Évalué à -3.
        
        Parce que tu crois que la sécurité c'est "j'y pense et puis j'oublie" ?
        Comme il est dit plus haut :
        
        si tu n'est pas capable de patcher OpenBSD, je ne crois pas que ça soit le système qu'il te faille.
        
        Utiliser un système pour sa sécurité sans se soucier activement de la sécurité de son installation c'est… euh… comment dire…
        
        "La liberté est à l'homme ce que les ailes sont à l'oiseau" Jean-Pierre Rosnay
        
        [^] # Re: Précisions
        
        Posté par Anonyme le 03 mai 2014 à 10:18. Évalué à 10.
        
        Parce que tu crois que la sécurité c'est "j'y pense et puis j'oublie" ?
        
        Pour moi c'est plutot "si une tache n'est pas automatisée, alors y a des chances qu'elle soit oubliée et/ou mal faite".
        
        Donc pour un systeme sécurisé je m'attend plutot à avoir un systeme qui:
        - me permet d'installer la mise à jour en une commande simple
        - me permet de verifier que la mise à jour est bien installée en une commande simple
        
        Utiliser un système pour sa sécurité sans se soucier activement de la sécurité de son installation c'est… euh… comment dire…
        
        Moi je prefere un systeme qui me facilite la sécurité, et ne m'oblige pas à m'en soucrier activement en patchant / recompilant à la main.
        
        [^] # Re: Précisions
        
        Posté par MTux le 03 mai 2014 à 21:32. Évalué à 1.
        
        Que ce soit fait par compilation ou avec apt-get n'a rien à voir avec le fait de mépriser les aspects de sécurité.
        Ce que je dis c'est qu'apt-get facilite la vie, et c'est vrai.
        
        OpenBSD est bien, mais quand je vois qu'il faut compiler les ports, compiler les mises à jour, j'ai l'impression d'être dans les années 80-90. En 2014 il serait quand même temps de développer un vrai gestionnaire de paquets, et fournir des binaires, car toutes les entreprises n'ont pas les moyens de payer 1 informaticien par serveur, sauf si tu bosses pour Google, donc tous les moyens sont bons pour gagner du temps.
        
        [^] # Re: Précisions
        
        Posté par ckyl le 03 mai 2014 à 22:29. Évalué à 5.
        
        toutes les entreprises n'ont pas les moyens de payer 1 informaticien par serveur, sauf si tu bosses pour Google, donc tous les moyens sont bons pour gagner du temps.
        
        Je pense que tu prends le mauvais exemple. Si on fais un calcul au dos de l'enveloppe pessimiste: ~2 millions de serveur pour au max 2000 SRE (ça ferait un ratio SWE:SRE de 4:1) ça nous fait minimum 1000 serveurs par personne (qui n'est pas dédié à plein temps à ça).
        
        C'est totalement inintéressant comme calcul, sauf qu'on est en 2014 et si tu fais du sysadmin manuel, à la papa, non automatisée "You're doing it wrong". D'ailleurs ils sont pas encore mort les sysadm ? :)
        
        [^] # Re: Précisions
        
        Posté par MTux le 03 mai 2014 à 23:20. Évalué à 2.
        
        Tu ne choisis pas forcément tes serveurs, tu arrives, c'est déjà en place, et parfois ce sont des vieux trucs. Donc non pas toujours des outils automatisés. D'ailleurs des outils comme Puppy permettent de compiler des mises à jour ? J'en doute.
        
        [^] # Re: Précisions
        
        Posté par claudex le 03 mai 2014 à 23:24. Évalué à 4.
        
        On peut très bien exécuter une commande avec Puppet http://www.puppetcookbook.com/posts/exec-a-command-in-a-manifest.html
        
        « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
        
        [^] # Re: Précisions
        
        Posté par barmic le 04 mai 2014 à 00:10. Évalué à 5.
        
        D'ailleurs des outils comme Puppy permettent de compiler des mises à jour ? J'en doute.
        
        Un gestionnaire qui ne te permet pas d'utiliser la gestion de paquets de l'OS installé est un très mauvais choix.
        
        Ensuite quand tu n'a pas de truc comme puppet, cfengine ou salt très centralisé tu peut te tourner vers fabric ou ansible qui ne requièrent pas de deamon sur les machines administrées (et qui permettent évidement d'exécuter des commande arbitraires).
        
        Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
        
        [^] # Re: Précisions
        
        Posté par Krunch (site web personnel) le 05 mai 2014 à 23:04. Évalué à 2.
        
        Puppet ne nécessite pas de daemon dédié. Tu peux très bien t'en sortir avec cron par exemple. C'est sans doute vrai pour cfengine et salt aussi mais je n'ai pas d'expérience direct en la matière.
        
        pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
        
        [^] # Re: Précisions
        
        Posté par PilouPilou le 04 mai 2014 à 10:02. Évalué à -3.
        
        OpenBSD est bien, mais quand je vois qu'il faut compiler les ports, compiler les mises à jour, j'ai >l'impression d'être dans les années 80-90. En 2014 il serait quand même temps de développer un vrai >gestionnaire de paquets, et fournir des binaires, car toutes les entreprises n'ont pas les moyens de payer >1 informaticien par serveur, sauf si tu bosses pour Google, donc tous les moyens sont bons pour gagner du >temps.
        
        Si tu penses ça, OpenBSD n'est clairement pas fait pour toi, et du coup, je ne vois pas pourquoi tu en parles.
        En plus, je pense que les gens de chez OpenBSD s'en cogne des avis comme le tient.
        
        [^] # Re: Précisions
        
        Posté par Anonyme le 04 mai 2014 à 12:27. Évalué à 4.
        
        En plus, je pense que les gens de chez OpenBSD s'en cogne des avis comme le tient.
        
        Et on s'en cogne que les gens de chez OpenBSD s'en cognent. Ce genre d'avis reste interessant pour les autres (non-)utilisateurs potentiels. Ca permet par exemple de savoir que OpenBSD c'est cool si tu veux t'amuser à compiler des trucs pour le fun, mais si tu cherches un OS pour faire des trucs faut utiliser autre chose.
        
        [^] # Re: Précisions
        
        Posté par anaseto le 04 mai 2014 à 15:57. Évalué à 7.
        
        Ca permet par exemple de savoir que OpenBSD c'est cool si tu veux t'amuser à compiler des trucs pour le fun, mais si tu cherches un OS pour faire des trucs faut utiliser autre chose.
        
        Je viens de passer mon serveur auto-hébergé sur OpenBSD, et je n'ai eu à compiler aucun port (les packages sont précompilés), et tous les services que j'utilise (serveur mail, web, ssh) sont de toutes façons inclus dans le système de base, à part le framework web (précompilé dans les ports). J'ai juste eu à compiler quelques patchs, principalement autour d'openssl, et la compilation a à peine pris une ou deux minutes sur une machine pas spécialement rapide (c'est pas tout le système qui se recompile, juste quelques trucs).
        
        Donc pour un serveur maison auto-hébergé c'est en tous cas très pratique. Je ne me prononce pas sur si c'est toujours ou non le cas pour un sys-admin avec mil serveurs, je n'en ai aucune idée.
        
        [^] # Re: Précisions
        
        Posté par Loïc Blot (site web personnel) le 04 mai 2014 à 12:35. Évalué à 5.
        
        Hello,
        sous OpenBSD tu n'as pas besoin de compiler les ports (c'est fortement déconseillé d'ailleurs). Tu utilises le repos avec pkg_add :)
        
        Puppet sait très bien gérer les repository OpenBSD, si tu mets package { "isc-dhcpd": ensure => installed } ca fonctionnera.
        
        Veepee & UNIX-Experience
        
        [^] # Re: Précisions
        
        Posté par Hobgoblins Master (Mastodon) le 04 mai 2014 à 13:28. Évalué à 1.
        
        sous OpenBSD tu n'as pas besoin de compiler les ports (c'est fortement déconseillé d'ailleurs). Tu utilises le repos avec pkg_add :)
        
        et tu lis ça comment :
        
        Also recompile any statically-linked binaries depending on it - in
        the base OS, this is just ftp(1)
        
        Vu qu’on ne sait pas quels ports binaires sont compilés en statique, et que je n’ai rien vu concernant une recompilation des ports binaires suite à heartbleed (d’ailleurs, je n’ai jamais vu de mises à jour en dehors des upgrades de ces paquets), faut-il en conclure qu’il faut tout recompiler ?
        
        Clairement, je ne vais pas faire l’upgrade sur ma soekris, quitte à avoir une demi journée de boulot et d’interruption de service, elle va repasser sous Debian, je pourrais utiliser les capacités 802.11n de la carte Wi-Fi et ne plus avoir + d’une heure d’arrêt pour les upgrades (et pour la sécurité, je reçois les mails de la liste sécu de Debian et j’installe apticron sur toutes mes machines, je peux réagir rapidement et en cas de faille, appliquer les mises à jour presque immédiatement sans attendre d’avoir 4h de libres…).
        
        J’ai essayé pendant près de 2 ans, OpenBSD n’est pas fait pour moi, pourtant, je suis sysadmin à la base…
        
        [^] # Re: Précisions
        
        Posté par Phil_S le 04 mai 2014 à 17:58. Évalué à 3.
        
        .. que je n’ai rien vu concernant une recompilation des ports binaires suite à heartbleed (d’ailleurs, je n’ai jamais vu de mises à jour en dehors des upgrades de ces paquets)
        Peut-être parce que la version d'OpenSSL livrée avec OpenBSD n'est pas vulnérable ?? Et ce depuis fort longtemps:
        
        Sur un vieux machin à moi :
        $ uname -a
        OpenBSD 4.8 GENERIC.MP#359 i386 (Oui, vraiment vieux)
        $ openssl version
        OpenSSL 0.9.8k 25 Mar 2009
        
        Côté logiciels tiers (en dehors de ceux préinstallés), je n'ai pas recompilé un port depuis des lustres; les packages binaires, me suffisent.
        
        [^] # Re: Précisions
        
        Posté par Anonyme le 05 mai 2014 à 10:50. Évalué à 1.
        
        […] j’installe apticron sur toutes mes machines, je peux réagir rapidement et en cas de faille […]
        
        Tu peux aussi regarder du coté d'unattended-upgrades qui s'occupe de mettre à jour les paquets en se basant sur les informations des dépôts sur lesquels ils sont (Origin:, Suite:, Label:, par exemple).
        
        En perso, mes VM se mettent à jour toutes seules ('o=Debian,a=stable', 'o=Debian,a=stable-updates'). En pro, j'ai pas encore décidé de ce que j'allais faire (ça sera sûrement les mises à jour de sécurité uniquement).
        
        Pour ceux qui utilisent Puppet avec le module puppetlabs-apt :
        
        class { 'apt::unattended_upgrades': origins => [ 'o=Debian,a=stable', 'o=Debian,a=stable-updates' ], mail_to => 'foo@example.com', }
        
        [^] # Re: Précisions
        
        Posté par MTux le 04 mai 2014 à 20:09. Évalué à 2.
        
        sous OpenBSD tu n'as pas besoin de compiler les ports (c'est fortement déconseillé d'ailleurs). Tu utilises le repos avec pkg_add :)
        
        C'est vrai mais les paquets binaires n'ont pas forcément les options qu'on veut.
        Par exemple dovecot avec le support de sqlite ou mysql.
        Cela peut sembler bête mais c'est très chiant.
        Sous FreeBSD, si on veut php-fpm, il faut compiler (c'est une option à passer dans le port "php", option non présente dans la version binaire).
        
        [^] # Re: Précisions
        
        Posté par Loïc Blot (site web personnel) le 04 mai 2014 à 21:44. Évalué à 2.
        
        C'est vrai, les paquets binaires utilisent les options par défaut des mainteneurs, généralement, et ce ne sont pas forcément celles adaptées au besoin de tous.
        
        Personnellement, en ce qui concerne FreeBSD j'ai ma propre poudriere en production qui fait son boulot de compilation tout seul, il faut juste prendre le temps de configurer une fois les ports et de temps en temps vérifier que les options n'ont pas changé (1 fois toutes les 2 semaines en ce qui me concerne)
        
        Veepee & UNIX-Experience
        
        [^] # Re: Précisions
        
        Posté par loran42o (site web personnel) le 05 mai 2014 à 13:58. Évalué à 1.
        
        Commentaire HS mais je viens d'installer les binaires php55 , php55-extensions et nginx via pkg(8) et j'ai bien php-fpm.
        > /usr/local/etc/rc.d % ls -l total 16 -r-xr-xr-x 1 root wheel 3559 24 avr 02:31 nginx* -r-xr-xr-x 1 root wheel 770 2 mai 08:33 php-fpm*
        Concernant OpenBSD, es-ce certains l'utilisent comme filer dans un environnement hétérogène (FreeBSD, Linux et Windows7) ?
        
        ça c'est fait ....
        
        [^] # Re: Précisions
        
        Posté par Bapt (site web personnel) le 05 mai 2014 à 19:41. Évalué à 2.
        
        php-fpm est par défaut maintenant elle est donc dans le binaire
      - [^] # Re: Précisions
        
        Posté par benpro (site web personnel) le 05 mai 2014 à 14:55. Évalué à 0.
        
        https://twitter.com/mtierltd/status/461249151402278912
        
        Je laisse ça là. C'est un dépôt alternatif avec des patchs binaires, pas besoin de recompiler :)
- [^] # Re: Précisions
  
  Posté par zebra3 le 02 mai 2014 à 15:47. Évalué à 10.
  
  Du coup, il va falloir changer le slogan sur la page d'accueil :
  
  Only three remote holes in the default install, in a heck of a long time!
  
  Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
  - [^] # Re: Précisions
    
    Posté par claudex le 02 mai 2014 à 15:51. Évalué à 5.
    
    Pas forcément, il suffit de définir a heck of a long time = le temps que 2 failles à distance se glissent dans l'installation par défaut.
    
    « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
  - [^] # Re: Précisions
    
    Posté par TeXitoi (site web personnel) le 04 mai 2014 à 01:37. Évalué à 4.
    
    Bah, non, heartbleed touche pas OpenSSH, et comme il n'y a pas de service qui utilisent ssl qui est lancé et ouvert sur le monde par défaut, il n'y a pas de "remote hole" en plus.
    - [^] # Re: Précisions
      
      Posté par Anonyme le 04 mai 2014 à 13:54. Évalué à 4.
      
      et comme il n'y a pas de service qui utilisent ssl qui est lancé et ouvert sur le monde par défaut, il n'y a pas de "remote hole" en plus
      
      Ah oui, c'est vrai que ca ne concerne que les trucs lancés et ouvert sur le monde par défaut. Sachant que personne utilise une install par defaut avec la conf par defaut, c'est juste un slogan marketing debile.
      - [^] # Re: Précisions
        
        Posté par Kerro le 04 mai 2014 à 17:03. Évalué à 3.
        
        c'est juste un slogan marketing ~~debile~~
        
        pléonasme
        nom masculin
        
        (bas latin pleonasmus, du grec pleonasmos, excès)
        
        Répétition dans un même énoncé de mots ayant le même sens, soit par maladresse (par exemple descendre en bas), soit dans une intention stylistique (par exemple Je l'ai vu, dis-je, vu, de mes propres yeux, vu [Molière]).
      - [^] # Re: Précisions
        
        Posté par Almacha (site web personnel) le 05 mai 2014 à 16:23. Évalué à 1.
        
        Ça dépend. Si tu utilises OpenBSD sur un routeur/firewall, alors effectivement l'argument des 2 failles est vrai. Par contre si il faut compter les failles de Apache, BIND, et Sendmail (tous les 3 fournis/anciennement fournis par OpenBSD mais pas activés de base) alors on est à probablement à des centaines de failles.
        
        [^] # Re: Précisions
        
        Posté par zebra3 le 05 mai 2014 à 16:29. Évalué à 4.
        
        Ici je ne pense pas qu'il faille parler d'une faille d'Apache puisqu'elle vient d'OpenSSL, qui fait partie du système de base.
        
        Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
        
        [^] # Re: Précisions
        
        Posté par Zylabon le 05 mai 2014 à 16:37. Évalué à 2.
        
        il me semble que l'histoire des deux failles c'est juste dans l'installation par défaut (et rien d'autre).
        
        Please do not feed the trolls
# M:Tier pour la MAJ binaire des paquets

Posté par ulver le 02 mai 2014 à 13:36. Évalué à 7.

Hello,

Merci pour ta dépêche, c'est une belle version que voilà.
D'après http://www.openbsd.org/faq/upgrade55.html#headsup , la suivante s'annonce aussi sympa :-)

A part ça, juste pour signaler pour ceux qui ne connaissent pas l'existence de https://stable.mtier.org/. C'est une société qui fournit des maj de sécurité pour les paquets en mode binaire, ce qui évite à avoir à les compiler dans son coin.
J'utilise le dépôt pour mon desktop et c'est juste nickel.

Visiblement, ils fournissent aussi de quoi mettre à jour le système de base, mais je n'ai pas encore essayé (ça éviterait par exemple de devoir compiler pour appliquer le patch Heartbleed).
# Taille du timestamp

Posté par Renault (site web personnel) le 02 mai 2014 à 13:57. Évalué à 6.

Le problème actuel de la variable time_t est qu'elle est codée sur 32 bits dans tous les systèmes UNIX. Le 19 janvier 2038 à 3h14 et 7 secondes cette variable atteindra sa valeur limite, causant des problèmes graves, avec la réinitialisation de celle-ci à zéro.

Normalement ce ne sont pas les UNIX version 32 bits qui sont concernés ? Et le noyau Linux n'a pas déjà fourni des correctifs pour résoudre le problème même sur 32 bits ?

Enfin, je me base de mémoire, cette phrase me paraît du coup trompeuse.
- [^] # Re: Taille du timestamp
  
  Posté par Loïc Blot (site web personnel) le 02 mai 2014 à 14:33. Évalué à 3.
  
  D'après Wikipedia, il semblerait que NetBSD, OpenBSD et Linux (x32 compris) aient fixé le problème
  
  Source
  
  J'aurais plutôt dû dire: "la plupart des systèmes UNIX"
  
  Veepee & UNIX-Experience
  - [^] # Re: Taille du timestamp
    
    Posté par claudex le 02 mai 2014 à 14:42. Évalué à 3.
    
    Linux (x32 compris)
    
    x32 ou x86 ?
    
    « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
    - [^] # Re: Taille du timestamp
      
      Posté par claudex le 02 mai 2014 à 14:43. Évalué à 4.
      
      Bon, j'ai lu le lien et ça n'a pas l'air d'être le cas pour x86.
      
      « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
  - [^] # Re: Taille du timestamp
    
    Posté par reno le 02 mai 2014 à 15:01. Évalué à 4.
    
    Oui, enfin la dernière fois que j'ai entendu parler de Linux/x32 c'était car il y avait une grosse faille qui était restée ignorée car personne n'utilisait x32, alors bon..
  - [^] # Re: Taille du timestamp
    
    Posté par ariasuni le 02 mai 2014 à 17:59. Évalué à 6.
    
    aient ~~fixé~~ corrigé le problème
    
    Écrit en Bépo selon l’orthographe de 1990
    - [^] # Re: Taille du timestamp
      
      Posté par Enj0lras le 03 mai 2014 à 13:32. Évalué à 3.
      
      Je crois que tout les systèmes Unix ont un time_t de 64bits depuis quasiment l'existence de 64bits.
      C'est en effet uniquement les version 32bits qui sont concernées.
# Commentaire supprimé

Posté par Chriss le 02 mai 2014 à 15:18. Évalué à -5. Dernière modification le 02 mai 2014 à 15:36.

Ce commentaire a été supprimé par l’équipe de modération.
# C'est vendredi... tout est permis

Posté par Frédéric Massot (site web personnel) le 02 mai 2014 à 19:09. Évalué à -5.

Dans la liste des logiciels inclus dans OpenBSD 5.5 vous avez oublié Systemd en Technology Preview.
- [^] # Re: C'est vendredi... tout est permis
  
  Posté par HanX (site web personnel) le 03 mai 2014 à 00:06. Évalué à -2.
  
  Encore une victoire de Lennart !
- [^] # Re: C'est vendredi... tout est permis
  
  Posté par Tonton Th (Mastodon) le 03 mai 2014 à 11:11. Évalué à 1.
  
  logiciels inclus […] en Technology Preview.
  
  Bah, tant que la grouille PulseAudio reste dans son coin…
# Mauvaise PUB

Posté par MTux le 05 mai 2014 à 21:25. Évalué à 4.

Et voilà, la mauvaise pub commence. C'est vraiment dommage voire impardonnable de sortir une version de l'OS le plus sécurisé du monde avec la faille de sécurité la plus connue du monde.
- [^] # Re: Mauvaise PUB
  
  Posté par lasher le 06 mai 2014 à 02:30. Évalué à 2.
  
  Celle où les animateurs de talk shows aux US disent que Heartbleed est un virus ? :-)
  
  Je pense que ceux qui connaissent le monde des *BSD savent de quoi il retourne. Parmi ceux qui connaissent le monde de Linux un certain nombre en sont sans doute encore à penser qu'il faut compiler tous les paquets à la main — alors qu'en fait, non, et que même s'il fallait, le système d'OpenBSD permet de compiler les paquets à recompiler une fois, puis de distribuer le binaire tranquillou pour les autres machines, comme n'importe quelle distribution UNIX ou UNIX-like moderne qui se respecte. Et idem pour FreeBSD et NetBSD.
  
  Par contre, je conçois qu'avoir un binaire compilé par un dev « officiel » d'OpenBSD et dispo quelque part (pas forcément le site d'O/BSD) pourrait quand même en rassurer certains.
# en desktop avec KDE

Posté par AgentSteel (site web personnel) le 07 mai 2014 à 20:31. Évalué à 6.

Agréablement surpris par cet OS.

KDE 4 fonctionne au poil (il manque bien sûr la gestion d'énergie, spécifique à Linux, mais sinon sur mon matos, du intel sur carte-mère avec chipset B75, j'ai la chance que la gestion d'énergie via apmd fonctionne, donc ça compense).

Beau boulot des devs :)

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.